Who should issue OpenID Connect Identity Tokens, SaaS or SSO IdP token providers?

Question

When implementing OpenID Connect, an identity (ID) token is required. When building a SaaS service that performs its own local login/authn and also delegates to 3rd party IdPs, such as via Single Sign-On, whose ID token should the SaaS service provide to the consumer of the SaaS service, and ID token generated by the SaaS service, or the ID token provided by the upstream IdP?

Also of note, the SaaS service supports, and must continue to support, SAML.

I've looked at both approaches but haven't found a definitive answer.

A benefit of having the SaaS service provide the ID token seems to be uniformity and consistency for all users on the system, regardless of what SSO provider they chose.

Answer 1

I tend to use the terminology from OAuth 2.0 since I think it defines roles in the clearest way. Usually OIDC is used in conjunction with OAuth 2.0.

Authorization Server

The party granting access uses one of these to issue consistent tokens to OAuth clients. The AS enables full control over token contents. This is the SaaS system in your question. OAuth clients only interact with their AS.

Identity Provider

There can be lots of these, eg:

• Google
• Facebook
• Apple

Your clients only interact with an AS, which in turn can interact with multiple IDPs.

The AS verifies IDP tokens and then issues its own tokens. The AS uses account linking to ensure that clients are issued consistent tokens regardless of the user's login method.

SAML Protocol

The concepts are the same in SAML and some systems (eg your SaaS provider) can act as both an AS and a SAML server.

• SAML clients can interact with a SAML server that integrates with upstream IDPs. The SAML client then receives a SAML assertion from the SAML server whose contents you can control.

• OAuth clients can interact with an AS that uses an upstream SAML IDP. The OAuth client then receives tokens from the AS whose contents you can control.