OpenID Connect 1.0

This section presents OAuth 2.0 and OpenID Connect 1.0 capabilities.

The Basic Client Profile is designed for web-based relying parties that use the OAuth 2.0 Authorization Code grant type, such as server-side clients that can protect their client credentials.

The Implicit Client Profile is designed for relying parties that use the OAuth 2.0 Implicit grant type, such as browser-based clients written in JavaScript.


Requested Authentication Context (acr_values):




Request individual claims

Authentication URL:


This section shows how to use the OpenAM RESTful interfaces for direct integration between web client applications and OpenAM.

Well-known OIDC Configuration:

GET ""

JSON Web Key Information:

GET ""
POST --user "sesam:password" --data "scope=openid profile&grant_type=password&auth_chain=ldapService&username=your-user-name&password=your-user-password" ""
POST --user "sesam:password" --data "scope=openid profile&grant_type=refresh_token&refresh_token=your-refresh-token" ""

Authorization code flow only.

GET ""

Endpoint not defined in RFC 6749. Resource server can perform an validation of access token, or retrieve information, such as scopes:

GET ""


ID Token:


ID Token:

GET --header "Authorization: Basic clientid:clientSecret" ""

ID Token:

Authorized clients can access end user information using an access token:

GET --header "Authorization: Bearer your-access-token" ""

When a user logs out of an application, the application revokes any OAuth 2.0 tokens (access and refresh tokens), that are associated with the user:


If you are revoking an access token, then that token will be revoked. If you are revoking a refresh token, then both the refresh token and any other associated access tokens will also be revoked. Associated access tokens means that any other tokens that have come out of the same authorization grant will also be revoked. For cases where a client has multiple access tokens for a single user that were obtained via different authorization grants, then the client will have to make multiple calls to the /oauth2/token/revoke endpoint to invalidate each token.

POST --header "X-OpenAM-Username: your-username" --header "X-OpenAM-Password: your-password" ""


GET --header "swissid: your-session-token" ""

GET --header "swissid: your-session-token" ""

Administrators can create a user profile:

POST --header "swissid: your-session-token" --data '{json-with-new-user-attributes}' ""

OpenAM lets users update their own profiles, and lets administrators update other users' profiles.

PUT --header "Content-Type: application/json" --header "swissid: your-session-token" --data '{json-with-changed-user-attributes}' ""


Administrators can delete a user profile by making HTTP DELETE call.

DELETE --header "swissid: your-session-token" ""

POST --header "swissid: your-session-token" ""

Server general information:

GET "*"
GET --header "Content-Type: application/json" --header "Authorization: bearer your-access-token" ""