Application Scenarios

Web Application using a backend API that trusts it

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 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 an active session with the web application.

When the web application accesses an API, it passes along the OIDC ID token. The ID 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 ID token lifetime is 4 hours.

The API in the backend can check the validity of the ID token without having to trust the web application. It thus receives confirmation that the user has an active (not older than 4 hours) session with the application.

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 ID-token for later use.

RP accesses backend API out of band

  1. RP sends request to API and sends raw ID token.
  2. API verifies ID token to check if user has a valid session with RP
    • checks the validity of the signature
    • checks aud: the id token was issued to the correct web application
    • checks exp: the id token has not expired.
  3. API responds to RP.

ID Token Example

{
  "aud": ”unidemo_student_info_system",
  "swissEduPersonUniqueID": ”8593726@eduid.ch",
"swissEduIDLinkedAffiliationUniqueID": ["642878@unidemo.ch",”398156@otheruni.ch"], "sub": "MA2ZRIYFC67J6ABXNA4LMSNQB7ZFMN5Y", "acr": "password", "iss": "https://eduid.ch/", "auth_time": 1617809173, "exp": 1617823587, "iat": 1617809187, "nonce": "Q0uCSy8GzEpvw…U8kXSSkyeMjPc" } + signature