Skip to main content

OIDC FAQs

FAQ

Q1: What are the differences between SAML and OIDC?

SAML and OIDC are two different protocols; OIDCs are usually easier to configure for mobile applications. For general web applications, you can choose either. However, if your application requires special attributes/claims that are not covered in Stanford Attribute Release policy, you would want to use SAML.

Additionally, in SAML, all communications are via "front-channel" (browser); in OIDC, it uses both "front-channel" and "back-channel". The back-channel is communication directly between the RP (application) and the OP (aka IDP). Your application server needs to be able to communicate with IdP which is currently hosted in Google Cloud.

For all enterprise web-based applications, we recommend using SAML as the primary authentication approach. However, if the application is not web-based or has specific requirements that SAML cannot fulfill, that’s when we suggest using OIDC.

Q2: What is the redirect_uri?

A redirect URI, or reply URL, is the location where the OIDC provider sends the user once the app has been successfully authorized and granted the authorization code. The OIDC provider sends the code or token to the redirect URI, so it's important you register the correct location as part of the app registration process.

Q3: What are the supported redirect_uri format for native apps?

Per RFC 8252, there are three main forms,

  • Private-Use URI Scheme redirection, ex: com.example.app, com.example.app:/oauth2redirect/example-provider
  • Claimed https scheme URI redirect, ex: https://app.example.com/oauth2redirect/example-provider
  • Loopback interface redirection, ex: http://127.0.0.1:51004/oauth2redirect/example-provider

Q4: What are the supported redirect_uri for web apps?

Strongly encourage users to start with https://. If you must use http://, then only with loopback address.

If you have multiple redirect_uri(s), you would want to change the "Subject Type" from "pairwise" (default) to "public" for your RP registration at spdb.

Q5: What are the lifetime for tokens?

 idp.oidc.authorizeCode.defaultLifetime = PT5M
 idp.oidc.accessToken.defaultLifetime = PT10M
 idp.oidc.refreshToken.defaultTimeout = PT2H
 idp.oidc.refreshToken.defaultChainLifetime = PT2H
 idp.oidc.idToken.defaultLifetime = PT1H

Q6: What is Userinfo endpoint?

The userinfo endpoint is used to retrieve user attributes. Clients use the access_token from the token response as a bearer token in the HTTP Authorization header. To request attributes, send an HTTP GET request to the /idp/profile/oidc/userinfo endpoint.

Q7: How to have OIDC provider releasing workgroup information to my application?

In the Service Provider Database (SPDB), under editing your RP, look for "Add Entitlement" (Send these workgroups(s)). Click on the '+' sign to add any public workgroup. Only non-private workgroups can be released directly from SPDB. There is a maximum of 20 workgroups per entity. If you need more, please submit a Help request via RP's page at SPDB.

The workgroup information is released under the "eduperson_entitlement" scope as the "eduPersonEntitlement" and "groups" claims. The "eduPersonEntitlement" claim presents the values as a space-delimited string, while the "groups" claim presents the values as a JSON array.

Q8: What if my vendor/application does not support PKCE?

PKCE (Proof Key for Code Exchange) is a security feature that protects the login process when using apps on the phone or computer, and it's enforced by Stanford's Identity Providers (IdPs). If a legacy application can't support PKCE, the owner can disable it as a last resort by checking "Disable PKCE" in SPDB.

Q9: How can I request the email claim in the id_token

If Relying Party (RP) wishes to receive the user's email as part of the id_token, this can be accomplished by using the claims parameter in the OpenID Connect authentication request.

  • Example JSON
 {
  "id_token": {
    "email": {
      "essential": true
    }
  }
}

URL-encoded form (for use in query string or mod_auth_openidc alike)

claims=%7B%22id_token%22%3A%7B%22email%22%3A%7B%22essential%22%3Atrue%7D%7D%7D

Note: Our OpenID Provider only allows the email claim to be requested in the id_token. All other claims are released via the userinfo endpoint.

Q10: How can I review my consent for a service I previously granted?

The default duration for consent is one year. If you want to review the consent you gave to a service, follow these steps:

  1. Find the Consent Option: Before submitting your login information, look for the checkbox that says "Review consent for sharing your info with this service." Make sure to check this box.
  2. Submit Your Request: Click the "Submit" button.
  3. Authentication: After you successfully log in, the consent screen for that specific service will appear, allowing you to review your consent.

Important Note for Cardinal Key (Certificate) Users: If you log in using a Cardinal Key, you may need to cancel the "Cardinal Key" login. This will redirect you to the regular Username/Password login screen, enabling you to make the necessary changes to review consent.

Known Issues

The presentation of acr claim is incorrect, see ISHIB-744.

Last modified