Access token

The lifetime of access tokens is 5 minutes.

Access tokens are by default opaque tokens, which are used to access the UserInfo endpoint to get the claims of the authenticated user.

However, access tokens can also be used to access resource servers where the trust between client and resource server is only established via the edu-ID. In this case, the access token is in the JWT format and contains more information which can be verified by the resource server before processing the request from the client. Support for resource servers is currently on the Roadmap and is to be implemented.

ID token

The lifetime of an ID Token is 4 hours.

By default, any ID Token contains the sub claim as well as some descriptive information about the token itself. The sub claim is a pairwise identifier which is a base32 salted hash of the username and the sector_identifier_uri given in the client description in the Resource Registry.

Since earlier the default was that some specific attributes are released as claims in the ID Token, some clients are still getting them due to backwards compatibilty. However, our goal is to not share any personal information about the user in the ID Token at all.

If for some reason you need any additional attributes in the ID Token please contact the edu-ID Team.

Find below an example ID Token:

  "at_hash": "qveVeMmfX3Gyd6l5YwqHZg",
  "aud": "apache_mod_openidc_testing",
  "acr": "password",
  "auth_time": 1646151333,
  "iss": "https:\/\/\/",
  "exp": 1646165737,
  "iat": 1646151337,
  "nonce": "Epg0I0IH3xeuZ2Em1JjzVmLZKX_M452HX0bBAIUAzeo",

Refresh token

The support for refesh tokens can be activated per client in the Resource Registry.

Refresh token properties:

  • refresh token lifetime: 30 days
  • the sucessful validation of the refresh token is a sucessful token response including an ID Token.
  • the use of a refresh token is made transparent to the user. After authentication the consent screen shows a message indicating that the service is allowed to retrieve identity data without further login for 30 days. A user may reject the consent and thus abort the login flow.

Clients that make use of refresh tokens should provide an option to revoke the refresh token. See the Token Revocation section below for details.

Note: The client gets a new refresh token with each sucessful request to the token endpoint. Consequently, it is possible that a user may have to re-authenticate only after more than 30 days, if the client was sufficiently often active in the mean time.

Token revocation

The edu-ID IdP supports token revocation according to RFC 7009. The revocation endpoint can be found on the discovery endpoint

Client applications that request and make use of refresh tokens are requested to offer token revocation for their users.

The OIDC currently does not support single logout (SLO). Token revocation mitigates the problem in part by cutting off access to a specific client.

Token introspection

The edu-ID IdP supports token introspection which can be used to verify that a given token is valid, according to RFC 7662. The introspection endpoint can be found on the discovery endpoint