OAuth 2.0 and OpenID Connect (OIDC) and SAML

(October 2023)

OpenID Connect (OIDC) is an authentication protocol widely adopted by identity providers. OIDC may be used for single sign-on across applications using JSON Web Tokens (JWT) to avoid sharing user secrets with other services. OIDC uses and extends OAuth 2.0.

OAuth is an authorization protocol for access delegation. OAuth is commonly used as a way for internet users to grant websites or applications access to their information on other websites but without disclosing their passwords.

(OAuth 2.0 is totally different from earlier OAuth versions; there’s no backwards compatibility. OAuth 2.0 is the only version in wide use, as of 2024.)

OIDC extends OAuth with an added scope value (openid), an extra JSON web token that encapsulates the identity claims, and a focus on authentication rather than authorization. OIDC talks about flows in place of OAuth’s grants.

An OIDC provider does authentication, user consent, and token issuance. The OpenID provider sets the authentication methods available to users (e.g., username/password, one-time code, biometrics). The OIDC specs don’t specify user authentication mechanics.

OAuth 2.0

OAuth 2.0 lets an application provide resources/data to client applications based on permissions granted by resource owners (end users).

The rationale for OAuth is to improve security versus the old/bad method of a user sharing their password for App A with client App B in order to allow client App B to access resources/data on App A. The OAuth spec (RFC 6749) introduces the problem and solution:

In the traditional client-server authentication model, the client requests an access-restricted resource (protected resource) on the server by authenticating with the server using the resource owner’s credentials. In order to provide third-party applications access to restricted resources, the resource owner shares its credentials with the third party. This creates several problems and limitations:

OAuth addresses these issues by introducing an authorization layer and separating the role of the client from that of the resource owner. In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner.

Instead of using the resource owner’s credentials to access protected resources, the client obtains an access token – a string denoting a specific scope, lifetime, and other access attributes. Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.

OAuth defines four roles:

Other important OAuth terms:

A typical exchange looks like this (though it can vary depending on the type of authorization grant):

  1. The Client asks the Resource Owner (the user) for authorization (or, preferably, the Client asks the Authorization Server to ask the Resource Owner).
  2. If the Resource Owner grants authorization, the Client passes that authorization grant to the Authorization Server. (Typically, the Client must register in advance to establish a relationship with the Authorization Server.)
  3. If the grant is valid, the Authorization Server returns an Access Token (possibly with a refresh and/or ID token).
  4. The Client uses the Access Token to ask Resource Server for resources.
  5. The Resource Server validates the access token. (Validation of the token isn’t covered by the OAuth standard. Validation might mean the resource server talks to the authorization server or there might be some kind of cryptographic signing mechanism.)
                                                    OAuth 2.0

                           |      Authorization Server      |
  +----------------------> |     (issues access tokens)     |
  |                        +--------------------------------+
  |                          |
  |                          |
  |                          v
  |                         "4. OK, here's an access token."
  |                          |
  |                          |
  |                          v
 "3. Here's a grant,       |               Client                |        "5. Give me resources
 so give me a token!"  <-- |        (app that wants data)        | --> (and here's an access token)."
                             |                                 ^         |
                             |                                 |         |
                             v                                 |         v
                                                               |       +------------------------------------------+
                            "1. Authorize?"                    |       |             Resource Server              |
                                                               |       |    (app/API/etc. that holds the data)    |
                             |                                 |       +------------------------------------------+
                             |                                 |            |
                             |                                 |            |
                             v                                 |            v
                           +--------------------------------+  |
                           |         Resource Owner         |  |           "6. Validate that the token
                           |      (user/owner of data)      |  |    authorizes the request and isn't expired."
                           +--------------------------------+  |
                             |                                 |
                             |                                 |
                             v                                 |
                            "2. OK, authorized!"  -------------+

A few things to note:

RFC 6749 says a successful response and token from authorization server might look like this:

 HTTP/1.1 200 OK
 Content-Type: application/json;charset=UTF-8
 Cache-Control: no-store
 Pragma: no-cache


RFC 6749 says:

Access tokens are credentials used to access protected resources. An access token is a string representing an authorization issued to the client. The string is usually opaque to the client. Tokens represent specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and authorization server.

The token may denote an identifier used to retrieve the authorization information or may self-contain the authorization information in a verifiable manner (i.e., a token string consisting of some data and a signature).


Access tokens can have different formats, structures, and methods of utilization (e.g., cryptographic properties) based on the resource server security requirements. Access token attributes and the methods used to access protected resources are beyond the scope of this specification and are defined by companion specifications such as [RFC6750].

RFC 6749 describes refresh tokens:

Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner). Issuing a refresh token is optional at the discretion of the authorization server. If the authorization server issues a refresh token, it is included when issuing an access token (i.e., step (D) in Figure 1).

A refresh token is a string representing the authorization granted to the client by the resource owner. The string is usually opaque to the client. The token denotes an identifier used to retrieve the authorization information. Unlike access tokens, refresh tokens are intended for use only with authorization servers and are never sent to resource servers.

RFC 6749 explains some of the security considerations of OAuth, such as client impersonation and phishing attacks.

OpenID Connect

OpenID Connect (OIDC) builds on OAuth. OIDC adds ID tokens in addition to the authorization and refresh tokens provided by OAuth.

OIDC terminology:

The flow for OIDC looks like the OAuth flow, except that an ID token is issued in addition to the authorization token.

RFC 7522 describes the claims in the ID token. Notably, sub is the subject identifier, and identifier locally unique to the application and never reassigned.

RFC 7522 specifies a list of standard claims for user information, and an issuer of ID tokens can add custom claims for use by its application.

ID tokens must be cryptographically signed to provide authentication, integrity, and non-repudiation, and optionally be encrypted to provide confidentiality.

	"iss": "",
	"sub": "24400320",
	"aud": "s6BhdRkqt3",
	"nonce": "n-0S6_WzA2Mj",
	"exp": 1311281970,
	"iat": 1311280970,
	"auth_time": 1311280969,
	"acr": "urn:mace:incommon:iap:silver"

The suggested pronunciation of JWT is the same as the English word “jot”.



Security Assertion Markup Language (SAML) is an open standar dthat defines teh syntax and exchange of security tokens that contain assertions about authentication, authorization, and attributes of a principle (e.g., an end user).

Like OIDC, Security Assertion Markup Language (SAML) provides a single sign-on mechanism.