Single-Sign On (SSO) at IGEL

Standards

Oauth v2.0

OpenID Connect

Oauth v2.0 / OpenID Connect Terminology

Resource owner: The person who owns an account, "you". Also RO, End user, subject (sub). Owns the resources and the identity,
Client: Application that wants to access data or perform actions on behalf of the resource owner. Also Relying Party (RP), Application (App), Audiences (Aud). Gets and holds Access Token, Refresh Token, and ID Token. Should NOT hold the password of the Resource Owner. Is identified via ClientID and ClientSecret.
Authorization server: The application that knows the resource owner who already has an account
Resource server; The API that the client can use on behalf of the resource owner. Sometimes, the authorization server and the resource server are on the same server; sometimes, they are in different organizations. Also API or endpoint. Protects resources with OAuth Access Token (coarse granular) and scopes. Makes resources available as RESTful API /api.
Userinfo Resource Server: A special resource server provided by the OpenID Connect Server. Holds userinfo resource with identity attributes (or "claims") of the Resource Owner. Protects userinfo resource with OAuth Access Token (coarse granular) and scopes and claims (fine granular). Makes userinfo resource available as RESTful API /userinfo.
OAuth Server: Also OAuth Provider, OP, Authorization Server (AS), Issuing Authority (ISS), Login Server, Token Issuer, Security Token Service (STS).
- Login screen: The OAuth server requires a login.
- Consent management: The client requests to access...
- Web application that allows the client to register itself in a self-service mode.
- Database that contains all tokens, and potentially, all metadata.
- Web application that allows the resource owner to revoke tokens.
OpenID Connect Server: Also OIDC Provider, OIDC Server, OP, Identity Provider (IdP), Issuing Authority (ISS), Login Server, Token Issuer, Security Token Service (STS). Similar to OAuth server, but in addition, it also has the userinfo endpoint, and it issues some more tokens.
- An authentication component for authenticating the end user, such as a login page and an identity provider.
- Consent management component for requesting the user's consent for sharing the identity information with the client.
- A token management component: It stores the tokens, their state, and links the tokens to the identity of the end user, to the client that requested the token, and to other tokens.
- A self-service registration component for clients. It is a web application, used by app developers to register their new apps with the OpenID Connect provider and to get credentials for the client (such as client ID and client secret).
- Userinfo resource server: provides userinfo in a standardized way.
Redirect URI (or: callback URL): The URL to which the authorization server will redirect the resource owner after granting permissions to the client.
Response Type: The type of information the client expects to receive. The most common response type is "Code", that is: an authorization code.
Scope: The permissions the client wants, e.g. read contacts, create contacts, ...
Consent: The authorization server takes the scopes the client is requesting and verifies with the resource owner whether he wants to give the client the desired permissions. Typically, a prompt with "allow" or "deny".
Client ID: Identifies the client with the authorization server.
Client secret: A password that only the client and the authorization server know. The client secret is issued by the authorization server and handed out to the client. This way, the authorization server can always authenticate the client.
Authorization code: A short-lived, temporary code the authorization server sends back to the client. The client then privately sends the authorization code back to the authorization server, along with the client secret, in exchange for an access token.
Access token: The key the client will use to communicate with the resource server on behalf of the resource owner.

Oauth 2.0 Flow

The resource owner wants to allow the client to use the owner's contacts and goes to the client's URL.
The client redirects the resource owner's browser to the authorization server. Included are the following items:
- Client ID
- Redirect URI
- Response type
- Scope
The authorization server verifies who the resource owner is: If there is no active session with the resource owner, the authorization server prompts for a login.
The authorization server presents the resource owner with a consent form based on the scope requested by the client. The resource owner grants permission.
The authorization server redirects back to the client using the redirect URI, along with a temporary authorization code.
The client contacts the authorization server directly (not via the resource owner's browser) and sends the following items to the authorization server:
- Authorization code
- Client ID
- Client secret
The authorization server verifies the data and responds to the resource server with the following items:
- Access token
The resource server verifies the access token. If it is valid, the resource server responds with the desired resources/actions - in our example, the contacts.

OpenID Connect (OIDC)

OpenID Connect is a thin layer that sits on top of Oauth v2.0. It adds login and profile information about the person who is logged in. OpenID Connect provides something like a badge; it gives the client specific permissions and provides information about who the person is. OpenID Connect enables a client to establish a login session.

When an authorization provider supports OIDC, it is sometimes called an identity provider (IdP).

With OpenID Connect, one login can be used for multiple applications, also known as Single Sign-On (SSO).

When OpenID Connect is used, the Oauth flow is almost the same, except in step 2, the scope is derived from OpenID Connect. An OpenID Connect exchange is performed. In step 7, the authorization server sends an ID token along with the access token. The ID token is a JSON web token (JWT). It includes the following information (called "claims"):

Issued by
Issued at
Expiration
User ID
E-mail
Name
When logged in
...?

Redirect Endpoint

HTTP redirect (302) Get <Redirect URI>

The response from the Authorization Endpoint is interpreted by the user agent (browser), which will load the page specified in the address in the location header.

HTTP location header example: https://www.mydomain.com/service?code=uiwjk2357&state=8730g0

(HTTP location header example for mobile apps: myApp://www.mydomain.com/service?code=uiwjk2357&state=8730g0)

Redirect URL: https://www.mydomain.com/service (app, website, or mobile app)
Authorization code: uiwjk2357

The redirect endpoint needs to read the Authorization Code from the query parameters.

IGEL OS Base System PUBLIC