OAuth¶

links: SPA TOC - Identification Authentication - Index

OAuth is an open standard for access delegation

No need to sign messages
Messages include bearer tokens
Simpler, but inherently less secure
TLS required

OpenID Connect is the authentication layer on top of OAuth 2.0. It allows computing clients to verify the identity of an end user based on the authentication performed by an authorization server.

In the following chapters Auth Server is used for the Authentication or Authorisation Server.

Roles¶

Resource Server: hosts the resources. Typically an API provider that hosts the user’s information.
Resource Owner: owns the resources. The resource owner is the person who is giving access to some portion of their account.
Client: makes API requests on behalf of the resource owner. Typically a web application or a mobile application. It needs to get permission from the user before it can do so.
Auth Server: gets consent from the resource owner and issues access tokens to client. In smaller implementations, this may be the same server as the API server, but larger scale deployments will often build this as a separate component.

Trust Relationship¶

The Client trusts the Auth Server to authenticate users and issue tokens.
The Resource Holder trusts the Auth Server to securely authenticate and not misuse credentials.
The Resource Server trusts the Auth Server to correctly validate users and trusts the token for access control.
The Resource Holder must also trust the Client to act on their behalf appropriately.

High level overview of the OAuth flow¶

The Resource Owner (Alice) asks the Client to to merge data.
The Resource Owner (Alice) authenticates to the Auth Server and authorises the Client to access it's information.
The Auth Server issues an Access Token to the Client.
The Client requests information from the Resource Server on the Resource Owners behalf.

Bearer Token¶

A bearer token is a type of access token. It's called "bearer" because it's not bound to any particular user or device - whoever "bears" the token can use it, which is why secure transmission and storage of these tokens are critical. It's often used in API authentication. It's passed in the Authorization header of a HTTPS request.

In OAuth we have two different tokens:

Access Tokens: Short-lived tokens used to access resources. They expire after a short duration for security reasons - if compromised, they are only valid for a limited time.
Refresh Tokens: Longer-lived and used to obtain new access tokens when the current access token expires. They allow the client to maintain access without needing the user to authenticate again.

The separation of these tokens enhances security. Even if an access token is compromised, it has a limited lifetime, and the attacker does not automatically gain long-term access.

Overview Client and Auth Server interaction¶

OAuth requires that the client registers with the authorisation server first.

Client asks user for permission to access resource server

Client redirects user to Auth Server
User authenticates and grants access to client
Auth Server redirects user to client and adds authorisation code
Client sends authorisation code to Auth Server
Client receives access token

Client can now access resource server using the access token

TLS requirements¶

As we are passing credentials and tokens around TLS is required. Every interaction with the Auth Server and the Resource Server MUST use TLS. For the Client it is heavily recommended.

Access Code vs Access Token¶

The general idea of using access codes instead of directly returning the tokens is to hide them from the end user. The second request is done usually by the backend server instead of a browser. So in the browser you just see a very short lived access code that you can only exchange for a token if you know the client_id and the client_secret.

For single page applications where everything is in the browser an extended flow is needed which we don't explain further: Authorisation Code Flow with Proof Key for Code Exchange (PKCE)

CSRF attack¶

Attack Scenario: An attacker could trick a victim into clicking a link or loading an image that initiates an OAuth authorisation request. If the user is already authenticated with the authorisation server, the attacker could obtain the authorisation code or token.
State Variable: The state parameter is a random string generated by the client and sent in the authorisation request. It should be verified when receiving the response. This check ensures that the response corresponds to the request made by the same user, preventing CSRF attacks by confirming that the authorisation flow was initiated by the actual user, not an attacker.

Example

Alice knows client ID and redirect URI of your web service.
Alice tricks Bob to visit her web app.
As soon as Bob visits her web app, it crafts an URL encoded authorisation request by using client ID and redirect URI of your web service and redirects Bob to the sign in page of the Identity Provider (IdP).
It's likely that Bob is already signed in at IdP so the IdP sends authorization code to the callback endpoint of your web service in the redirect response.
Your callback endpoint will use the authorisation code to exchange token and set cookies which will sign Bob in even though Bob has never visited your web app.

A resource holder (user) can revoke their consent typically through the service's user interface, where they manage third-party app permissions, or via an API endpoint provided by the resource server or authentication server.

Security Mechanisms¶

Access Tokens: OAuth relies on access tokens to ensure that user credentials are not passed around unnecessarily. These tokens grant limited access rights and are short-lived.
HTTPS: OAuth requires HTTPS for all exchanges involving tokens and sensitive data to prevent interception and eavesdropping.
Token Scopes and Lifetimes: Limiting the scope and duration of access tokens reduces the risk in case of token compromise.
Client Authentication: OAuth clients (third-party services) must authenticate themselves to the authorisation server, ensuring that tokens are only issued to legitimate clients.
Authorisation Grant Types: OAuth defines various grant types for different scenarios, like authorisation code, implicit, client credentials, and refresh tokens, each designed to address specific security and functionality needs.

OpenID Connect¶

Authentication Layer¶

Integration with OAuth 2.0: OpenID Connect is built on top of OAuth 2.0. It uses OAuth 2.0 flows for authentication, where an identity token is added to the OAuth access token.
Authentication Process: When a user attempts to access a resource requiring authentication, the service redirects them to the OpenID Provider (OP). The user logs in, and the OP authenticates the user's identity.
Token Issuance: After successful authentication, the OP issues an ID token and an access token. The ID token is a JWT (JSON Web Token) containing the user's identity information.
Token Validation: The service validates the ID token to confirm the user's identity and may use the access token to fetch additional user information from the OP.

Benefits¶

Single Sign-On (SSO): Users can authenticate once and access multiple services without re-entering credentials.
Standardisation and Interoperability: OpenID Connect provides a standardized way for services to authenticate users, facilitating integration with different identity providers.
Security: Improved security with tokens that are short-lived and can be validated for authenticity.

Trust Relations¶

The trust is established between the user, the OpenID Provider (which authenticates the user), and the relying party/service (which trusts the OP to authenticate users).

Identity Provider Interface¶

Delegation: OAuth allows users to grant a third-party service access to their information stored with another service, without exposing their credentials.
Scopes and Consent: OAuth scopes allow users to specify the level of access granted to third-party services. Users explicitly consent to these scopes during the OAuth flow.
Access Tokens: OAuth uses access tokens to grant third-party services limited access to user data, typically without revealing the user's identity (which is where OpenID Connect comes into play to add the identity layer).