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.

Known Issues

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