Auth Code Flow 2.0 vs CIBA

Auth Code Flow 2.0

The Authorization Code Flow is designed for applications that interact with protected APIs, particularly web or server applications that require user authentication and aim to avoid exposing sensitive credentials such as passwords or tokens.
OAuth (Open Authorization) is an open standard that allows applications to gain limited access to protected resources on behalf of a user without exposing their credentials (like passwords). This protocol is widely used to securely delegate permissions in web, mobile, and desktop applications.
Security through Two-Factor Authentication (2FA): This process adds a security layer by generating and validating an access token through a controlled authorization flow.

1. Components
o Client: The application requesting access to protected resources.
o User (Resource Owner): The owner of the data or protected resources.
o Authorization Server: Where the user logs in and grants access.
o Resource Server: Stores protected data and responds to authorized requests.
o Authorization Code: A temporary code used to obtain access tokens and/or refresh tokens.

2. Step-by-Step Flow

a. Initial Redirection

The client redirects the user to the authorization server.
The URL includes the following parameters:
o response_type=code: Indicates that an authorization code is being requested.
o client_id: The identifier of the client registered with the server.
o redirect_uri: The URL where the server will send the response after authentication.
o scope: The requested permissions (e.g., access to emails, contacts).
o state: A random value to prevent CSRF attacks.

b. User Consent

o The user logs in and either grants or denies the client permissions.
o If access is granted, the authorization server redirects the client to the specified redirect_uri.

c. Obtaining the Authorization Code

The redirection includes an authorization code and a state (if sent).
Example: https://app.com/callback?code=AUTH_CODE&state=STATE

d. Exchanging the Code for a Token

The client sends a POST request to the authorization server with:
o grant_type=authorization_code
o The authorization code.
o client_id and client_secret (for confidential applications).
o The redirect_uri matching the one registered.
If valid, the server responds with:
o An access token (to access protected resources).
o Optionally, a refresh token (to renew access).

e. Accessing Protected Resources

The client uses the access token to make requests to the resource server’s endpoints.
o If the access token expires, the client can use the refresh token to request a new one.

3. Benefits of Auth Code Flow

1. Enhanced Security:
   o User credentials are not directly handled by the client.
   o Access tokens are requested on the backend, protecting them from potential frontend attacks.
2. Support for Scopes:
   o Requested permissions can be limited to reduce risks.
3. Scalability:
   o Widely supported standard that integrates well with modern services like Google and Facebook.
   4. Security Considerations
   o State Parameter: Prevents attacks like Cross-Site Request Forgery (CSRF).
   o Client Secret: Should only be stored on secure servers, not in public clients like SPAs or mobile apps.
   o HTTPS Usage: Mandatory to protect the transmission of codes and tokens.
   5. Common Use Cases
   o Auth Code Flow: Best suited for applications requiring active user interaction with full interfaces.

CIBA (Client-Initiated Backchannel Authentication)

CIBA allows a client (e.g., an app or device) to initiate an authentication process where:
o The user does not directly interact with the client.
o Authentication happens through a secure out-of-band channel (backchannel), like a mobile device or push notification.

1. Components
o Client: The application or device requesting user authentication.
o Authorization Server: Manages user authentication and token issuance.
o User (Resource Owner): The person authenticating the client’s request.
o Backchannel: Secure communication between the client and the authorization server, without direct user interaction.
o Frontchannel (optional): For confirmation or user interaction in some cases.

2. CIBA Authentication Flow

1. Initial Authentication Request:
   o The client sends a request to the authorization server specifying:
   o The user’s identity to authenticate (e.g., phone number or email).
   o Client details and the request’s scope.
   o A client notification endpoint (optional) for the response.
2. User Notification:
   o The authorization server notifies the user through an external channel, such as:
   o A push notification to their mobile device.
   o An SMS or email.
   o The user is directed to an interface to authenticate the request (e.g., a mobile app).
3. User Decision:
   o The user reviews the request on their authorized device and approves or denies it.
   o If approved, the authorization server validates the authentication.
4. Token Issuance:
   o The authorization server responds to the client through the backchannel:
   o If authentication is successful, the client receives an access token.
   o If it fails or is denied, an error is reported.

3. Key Features of CIBA

1. No Client-Side Interaction:
   o Users don’t need to authenticate directly on the client; authentication occurs out-of-band.
2. Trusted Devices:
   o User interaction happens on a pre-authorized device, like their mobile phone.
3. Real-Time Notifications:
   o The authorization server can push notifications or messages to the user.
4. Asynchronous Flows:
   o Supports scenarios where the client doesn’t require an immediate user response.
   4. Security and Best Practices
   o Secure Channels: HTTPS is mandatory to protect communications.
   o Device Authorization: Devices must be registered as trusted beforehand.
   o Attack Prevention: Measures such as authentication time limits and integrity validations are key.
   5. Common Use Cases
   o IoT Authentication: Devices like smart thermostats authenticate while users approve on their mobile devices.
   o Contactless Banking Access: Users confirm their identity via mobile for ATM transactions.
   o Smart Device Authorizations: TVs, gaming consoles, or voice assistants.

Backend vs Frontend Scenarios

o CIBA: Ideal for IoT or scenarios where user interaction on the requesting device is unnecessary.
o Auth Code Flow: Suited for applications with active user interaction, like web or mobile apps needing credential confirmation in secure environments.