from flask import Flask
from flask_sslify import SSLify

app = Flask(__name__)
sslify = SSLify(app)  # Enforces HTTPS

@app.route('/')
def index():
    return "Secure API Endpoint"

const jwt = require("jsonwebtoken");

// Secure endpoint
app.get("/api/resource", (req, res) => {
  // Get token from headers
  const token = req.headers["authorization"]?.split(" ")[1];
  
  if (!token) {
    return res.status(401).json({ error: "No token provided" });
  }

  // Verify token
  jwt.verify(token, process.env.JWT_SECRET, (err, decoded) => {
    if (err) {
      return res.status(403).json({ error: "Invalid token" });
    }
    
    // Access granted - proceed with request
    // ...
  });
});

// Example refresh token rotation implementation
app.post("/token", (req, res) => {
  const { grant_type, refresh_token } = req.body;
  
  if (grant_type !== "refresh_token") {
    return res.status(400).json({ error: "Invalid grant type" });
  }
  
  // Validate the refresh token
  validateRefreshToken(refresh_token)
    .then(userData => {
      // Invalidate the old refresh token
      invalidateRefreshToken(refresh_token);
      
      // Generate new access and refresh tokens
      const newAccessToken = generateAccessToken(userData);
      const newRefreshToken = generateRefreshToken(userData);
      
      // Store the new refresh token
      storeRefreshToken(newRefreshToken, userData.id);
      
      // Return the new tokens
      res.json({
        access_token: newAccessToken,
        refresh_token: newRefreshToken,
        token_type: "Bearer"
      });
    })
    .catch(err => {
      res.status(401).json({ error: "Invalid refresh token" });
    });
});

// Example of strict redirect_uri validation
function validateRedirectUri(providedUri, allowedUris) {
  // Exact match validation - no wildcards or partial matches
  return allowedUris.includes(providedUri);
}

// Usage
const clientAllowedRedirectUris = {
  'client123': ['https://app.example.com/callback', 'https://app.example.com/auth/callback']
};

app.get('/authorize', (req, res) => {
  const { client_id, redirect_uri } = req.query;
  
  // Validate the redirect_uri
  if (!validateRedirectUri(redirect_uri, clientAllowedRedirectUris[client_id] || [])) {
    return res.status(400).json({ error: 'Invalid redirect_uri' });
  }
  
  // Continue with authorization flow
  // ...
});

// Generate a secure state parameter
function generateState() {
  return crypto.randomBytes(32).toString('hex');
}

// Store state in session
app.get('/login', (req, res) => {
  const state = generateState();
  req.session.oauth_state = state;
  
  const authUrl = `${authorizationServerUrl}?response_type=code&client_id=${clientId}&redirect_uri=${redirectUri}&state=${state}`;
  res.redirect(authUrl);
});

// Validate state in callback
app.get('/callback', (req, res) => {
  const { state, code } = req.query;
  
  // Verify state parameter
  if (!state || state !== req.session.oauth_state) {
    return res.status(403).json({ error: 'Invalid state parameter' });
  }
  
  // Clear state from session
  delete req.session.oauth_state;
  
  // Continue with code exchange
  // ...
});

1. Broken Object Level Authorization (BOLA)

Risk: Attackers exploit flaws in authorization to access unauthorized resources.

Mitigation:

• Implement proper authorization checks at every API endpoint
• Ensure users can only access resources they’re authorized for
• Regularly test APIs for authorization flaws

2. Broken Authentication

Risk:

Risk: Attackers can impersonate legitimate users due to weak authentication.

Mitigation:

• Enforce strong password policies and MFA
• Securely store and manage authentication tokens
• Implement rate limiting to prevent brute-force attacks

3. Excessive Data Exposure

Risk: APIs often expose more data than necessary, providing attackers with opportunities to harvest sensitive information.

Mitigation:

• Review API responses to ensure only necessary data is returned
• Implement data filtering and masking for sensitive information
• Adopt a “least privilege” approach to data access

4. Lack of Resources & Rate Limiting

Risk: APIs without proper rate limiting are vulnerable to abuse and DoS attacks.

Mitigation:

• Implement rate limiting to control request volume
• Use API gateways to distribute traffic
• Monitor API usage and adjust limits as needed

5. Broken Function Level Authorization

Risk: Users can access functions they shouldn’t have permission to execute.

Mitigation:

• Apply role-based access control (RBAC)
• Validate user permissions before executing critical functions
• Regularly audit API endpoints for function-level authorization flaws

OAuth 2.0 is an authorization framework that allows applications to access resources on behalf of users without sharing credentials. OpenID Connect extends OAuth 2.0 by adding an authentication layer, providing a standardized way to verify user identity.

While OAuth 2.0 answers “what can this application do on behalf of the user?”, OpenID Connect answers “who is this user?”. The key technical difference is that OIDC introduces the ID token, a JWT containing verified information about the user’s identity.

The recommended OAuth 2.0 flow depends on your application type:

• Server-side web applications: Use the Authorization Code flow
• Single-page applications (SPAs): Use the Authorization Code flow with PKCE
• Mobile applications: Use the Authorization Code flow with PKCE
• Machine-to-machine applications: Use the Client Credentials flow
• Devices with limited input capabilities: Use the Device Authorization flow

The Implicit flow is now deprecated due to security concerns and should be avoided in new implementations.

To prevent token leakage:

1. Use the Authorization Code flow with PKCE instead of the Implicit flow
2. Store tokens securely (memory or HTTP-only cookies for browsers, secure storage for mobile)
3. Set short token lifetimes and implement refresh token rotation
4. Use HTTPS for all communications
5. Implement proper CORS and referrer policies
6. Monitor for suspicious token usage patterns
7. Have a token revocation mechanism for compromised tokens

According to OWASP, the most common OAuth 2.0 vulnerabilities include:

1. Insufficient redirect_uri validation, allowing attackers to steal tokens through malicious redirects
2. Missing or improper state parameter validation, enabling CSRF attacks
3. Exposure of client secrets in frontend code
4. Token leakage through referrer headers or browser history
5. Insufficient access token validation by resource servers
6. Overly permissive scopes, granting more access than necessary
7. Lack of proper token storage and management

Video Thumbnail Placeholder

Video Thumbnail Placeholder

Video Thumbnail Placeholder