Stanford University IdPs support OpenID Connect, which can be used for the following use cases:
Confidential clients:
- Server-based web applications
- Native applications
The OpenID Connect protocol is provided by the same Shibboleth IdP instance that also supports SAML.
Features
Some common features with both OIDC and SAML include
- Usage of the same underlying user accounts and attribute information
- A user will see the same login user interface
- All applications are required to use 2-step authentication
- Cardinal Keys will work for both
There are also some differences:
- Some attribute names(claims) are different
- OIDC relying party has a password component which expires in a year
- OIDC requires user consent for releasing attributes (claims)
Requirements
- For all enterprise web-based applications, we recommend using SAML as the primary authentication approach.
- Presently, only the authorization code flow (response_type=code) is supported.
- Relying Parties must be registered by qualified Stanford personnel via spdb, much like SAML SP.
- PKCE is strongly encouraged and enforced in production
- OIDC IdP Discovery endpoints:
Get help
Learn more
- OpenID Connect Core - https://openid.net/specs/openid-connect-core-1_0.html
- OpenID Connect Discovery - https://openid.net/specs/openid-connect-discovery-1_0.html
- Proof Key for Code Exchange by OAuth Public Clients (PKCE) - https://tools.ietf.org/html/rfc7636
- OAuth 2.0 for Native Apps - https://www.rfc-editor.org/rfc/rfc8252.html
