Introduction to OIDC and OAuth

OAuth 2.0

OAuth 2.0 is a protocol used to access HTTP resources (API:s) on behalf of the user (resource owner) without sharing the user’s credentials. It’s the most commonly used standard for IAM today and used by large social media platforms as Facebook, Google and Twitter.

OpenID Connect

OpenID Connect (OIDC) is an identity layer on top of OAuth 2.0 that makes it easy to verify a user’s identity and retrieve basic information about the user from the identity provider. This allows applications to verify the identity of the end-user and retrieve this information as JSON web tokens (JWTs) using one of the grant types confirming to the OAuth 2.0 specification.

OAuth Grant Types and How to Choose?

The OAuth 2.0 protocol defines different grant types for obtaining access tokens:

• Authorization Code (section 4.1)
• Authorization Code with PKCE
• Client Credentials (section 4.4)
• Device Code
• Refresh Token (section 1.5)
• Implicit (section 4.2) (legacy so not recommended)
• Resource Owner Credentials (section 4.3) (legacy so not recommended)

Authway by IRM have support for all, except for Device Code (typically used on devices like televisions). Since we don’t support Device Code and both Implicit and Resource Owner Credentials are not recommended the choice is between Authorization Code or Client Credentials. To choose between these two the only question you need to answer is if it is an end-user that is signing in or if it is a system-to-system use case? For system-to-system access you should use Client Credentials and for end-user scenarios you should use Authorization Code, preferably with PKCE since it is more secure.

Explaining the Grant Types

Before explaining the grant types, let’s take a look at the different OAuth roles.

• Resource Owner: Entity that can grant access to a protected resource. Typically, this is the end-user (User).
• Resource Server: Server hosting the protected resources. This is the API you want to access.
• Client: Application requesting access to a protected resource on behalf of the Resource Owner.
• Authorization Server: Server that authenticates the Resource Owner and issues access tokens after getting proper authorization.

Client Credentials

The Client Credentials grant type is the simplest of all and it uses a client_id and client_secret credentials of a Client to authorize and access protected data from a Resource Server.

1. The client application makes a token request to the authorization server by providing the client credentials.
2. The authorization server authenticates the client and issues an access token.
3. The client application uses the access token when requesting resources from the resource server.

External systems

A challenge for a resource server that wants to support both system-to-system and end-user access tokens is that the contained claims in the tokens will be very different. For an end-user you’ll have claims for name, email, tid (tenant id), role and perm (permission), but a system-to-system access token will only have claims like client_id and client_name. This can be cumbersome to handle when validating access permissions and logging for example who have changed in data.

To make it easier for a resource server Authway have a concept called External system. An external system is a combination of a configured client and an user. Authway also overrides the standard token creation so that the token will include claims like name, tid and perm even in the Client Credentials grant.

Authorization Code (with PKCE)

The Authroization Code grant type is the most commonly used grant type to authorize the client and user access to protected data from a resource server. This uses browser redirections for communication and it provides some important security benefits such as the ability to do the authentication without the access token passing through the user-agent and potentially exposing it to others. This grant type can be used for SPA and native applications too, but in these scenarios it is usually with the access token in the user-agent. For SPA this can be avoided by creating a backend for frontend to increase the security.

1. Resource owner tries to access the client application via his user agent.
2. The client application makes an authorization request to the authorization server.
3. The authorization server authenticates the resource owner.
4. Authorization server sends a temporary Authentication Code back to the client.
5. The client application makes a token request to authorization server with the authorization code.
6. If the token request is valid, the authorization server returns the access token, expiration time and a refresh token (if requested).
7. Finally, the client application uses the access token when requesting resources from the resource server.

Refresh Token

The Refresh Token grant is used by clients to exchange a refresh token for an access token when the access token has expired. When an access token is obtained using authorization code grant type or client credentials grant type, to give additional security it has been designed to expire after the given token expiration time. In this case without end users interaction, authorization server will validate the refresh token and issue a new access token.