(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.
https://datatracker.ietf.org/doc/html/rfc6749
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:
- Third-party applications are required to store the resource owner’s credentials for future use, typically a password in clear-text.
- Servers are required to support password authentication, despite the security weaknesses inherent in passwords.
- Third-party applications gain overly broad access to the resource owner’s protected resources, leaving resource owners without any ability to restrict duration or access to a limited subset of resources.
- Resource owners cannot revoke access to an individual third party without revoking access to all third parties, and must do so by changing the third party’s password.
- Compromise of any third-party application results in compromise of the end-user’s password and all of the data protected by that password.
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):
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
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
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.
https://openid.net/specs/openid-connect-core-1_0-final.html
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": "https://server.example.com",
"sub": "24400320",
"aud": "s6BhdRkqt3",
"nonce": "n-0S6_WzA2Mj",
"exp": 1311281970,
"iat": 1311280970,
"auth_time": 1311280969,
"acr": "urn:mace:incommon:iap:silver"
}
https://openid.net/specs/draft-jones-json-web-token-07.html
The suggested pronunciation of JWT is the same as the English word “jot”.
(What!?)
http://docs.oasis-open.org/security/saml/v2.0/ http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
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.