Usage Patterns

Web Application using a backend API with mutual trust

SAML & OIDC

In this scenario, a user logs in to a web application where all user interaction takes place nad the session is managed. The web application accesses user data in backend services using a common identifier. The backend APIs are not "aware" of edu-ID.

app-trusting-apis

OIDC Authentication

  1. User accesses the application (RP) in the browser (on PC or mobile phone)
  2. User authenticates at OP. OP sends authorization code to RP via front channel (browser)
  3. RP trades authorization-code for tokens

SAML Authentication (edu-ID only configuration)

  1. User accesses the RP in the browser (on PC or mobile phone)
  2. User authenticates at IdP. IdP responds with attribute assertion. RP sets session (cookie).

RP accesses backend API out of band

  1. RP sends request to API and identifies user by unique-ID.
  2. API trusts RP and sends response.

 

Web Application using a backend API that trusts the OP

OIDC only

In this scenario a user authenticates for a web application. In the course of use, the application must access user data via APIs from third-party systems. The third party system is not in the same security domain and therefore requires independent confirmation that the user has allowed the web application to access 3rd party services.

When the web application accesses an API, it passes along the OIDC access token. The access token is signed by the edu-ID IdP and contains the user's identifier as well as the expiration date (see ID token example below). The access token lifetime is usually 10 minutes.

The API in the backend can check the validity of the access token without having to trust the web application. It thus receives confirmation that the user has allowed the access to the API. Since the access token is in JWT format, the validity check can be performed without interaction with the IdP.

app-nontrusting-apis

OIDC Authentication

  1. User accesses the application (RP) in the browser (on PC or mobile phone).
  2. RP redirects to OP.
  3. OP redirects back to RP with authorization-code (via front channel).
  4. RP requests ID token and access token.
  5. OP verifies authorization-code and returns tokens. RP keeps access token for later use. The access token is in JWT format (not opaque).

RP accesses backend API out of band

  1. RP sends request to API and sends the access token.
  2. API verifies access token to check if user has allowed the RP to access the API. This check can be done with information provided by the access token itself. No access to the OP is required.
    • check the validity of the signature
    • check iss: the correct OP as issuer of the token
    • check client_id: the access token issued to the RP
    • check aud: the access token was also issued to the API
    • check exp: the id token has not expired.
  3. API responds to RP.

It the API fails to verify the access token, it sends a negative response back to the application. It's the application's responsibility to get a valid access token, either by using a refresh token or by re-authenticating the user.

Access Token Example (simplified)

{
  "iss": "https://eduid.ch/", 
  "sub": "MA2ZRIYFC67J6ABXNA4LMSNQB7ZFMN5Y", 
  "aud": ["https://grades-api.example.com","https://lms-api.example.com"],
  "client_id": "unidemo_student_info_system",
  "exp": 1617823587,
  "iat": 1617809187,
  "scope": "grades courses"
} + signature

References:

  • JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens (RFC 9068)