OpenID Connect (OIDC)
- Authentication protocol
- Authentication is a secure process of establishing and communicating that the person operating an application or browser is who they claim to be.
- Provides a secure and verifiable answer to the question “What is the identity of the person currently using the browser or mobile app that is connected?”
- Based on the OAuth 2.0
- OAuth 2.0, is a framework, specified by the IETF in RFCs 6749 and 6750 (published in 2012) designed to support the development of authentication and authorization protocols. It provides a variety of standardized message flows based on JSON and HTTP; OpenID Connect uses these to provide Identity services.
- Simplifies:
- user identity verification
- based on the authentication performed by an Authorization Server
- obtaining user profile information
- in an interoperable and REST-like manner
- Specification extendable to support optional features like:
- encryption of identity data
- discovery of OpenID Providers
- session logout
- Benefits for developers:
- Easy, reliable, secure
- Removes the responsibility of setting, storing, and managing passwords - they are stored with OpenID providers
- There are already system-level APIs built into the Android operating system to provide OIDC services
- OIDC can also accessed by interacting with the built-in system browser on mobile and desktop platforms; a variety of libraries are under construction to simplify this process.
- OIDC uses standard JSON Web Token (JWT) data structures when signatures are required. This makes OpenID Connect dramatically easier to implement, and in practice has resulted in much better interoperability.
Entities in the oidc system
- OpenID Provider (OP)
- Entity that has implemented the OpenID Connect and OAuth 2.0 protocols
- Sometimes can be referred to by the role it plays, such as:
- Identity provider (IDP, IdP) - IdentityServer
- Security token service
- Authorization server
- Leading IdPs are currently large cloud services providers, such as Auth0, GitHub, GitLab, Google and Microsoft
- Identity Token
- The outcome of an authentication process
- After successful authentication, OP returns it to the Client
- It can contain additional identity data but at a bare minimum it contains the following claims:
- iss -Issuer Identifier for the Issuer of the response. The iss value is a case-sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components.
- sub - Subject Identifier. Identifier for the user at the issuer. A locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client, e.g., 24400320 or AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4.
- aud - Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value. It MAY also contain identifiers for other audiences. In the general case, the aud value is an array of case-sensitive strings. In the common special case when there is one audience, the aud value MAY be a single case-sensitive string.
- exp - Expiration time on or after which the ID Token MUST NOT be accepted by the RP when performing authentication with the OP. The processing of this parameter requires that the current date/time MUST be before the expiration date/time listed in the value. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. Its value is a JSON [RFC8259] number representing the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time.
- iat - Time at which the JWT was issued. Its value is a JSON number representing the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time
- The full list of claims returned within the token: https://openid.net/specs/openid-connect-core-1_0.html#IDToken
- Access Token
- After successful authentication, OP usually returns it to the Client
- User
- person that is using a registered client to access resources
- Client
- also known as audiences
- software that requests tokens for:
- authenticating a user
- accessing a resource (also often called a relying party or RP)
- must be registered with the OP
- ClientID is used to identify a client app to IdP servers e.g. for Google OAuth this is in form 1234567890-abcdefghijklmnopqrstuvwxyz.apps.googleusercontent.com
- When a mobile or web app registers with an OpenID Connect provider, they establish a value that identifies the application. (This is the value that's sent as the client_id parameter on OAuth requests.)
- can be web, mobile, desktop application
- Relying Party (RP)
- resource that user wants to access
- an application or website that outsources its user authentication function to an IDP
- application (software) that requires end-user authentication or wants to get access to the user's account.
- It needs to get permission from the user before it can get access to the user's account
- OpenID Connect identifies a set of personal attributes that can be exchanged between Identity Providers and the apps that use them and includes an approval step (aka authorization) so that users can consent (or deny) the sharing of this information.
- OIDC Relying Party is also called just a 'client' in OAuth terminology. (source: OIDC Relying Party)
Approval step (scope authorization) dialog looks like this:
OpenID Connect protocol steps
- User navigates to a website or web application (RP) via a browser
- User clicks sign-in and types their username and password
- RP (Client) sends a (authorisation) request to the OpenID Provider (OP)
- OP authenticates the User and obtains authorization
- OP responds with an Identity Token and usually an Access Token
- RP can send a request with the Access Token to the User device
- UserInfo Endpoint returns Claims about the User
Here is a more detailed flow diagram:
Resources:
No comments:
Post a Comment