Authenticating with 3rd-party ID Token

Question

If an ID token is used to identify and authenticate a person, then I can use ID tokens from 3rd-party OpenID Connect providers as a means to authenticate users to my API.

Verification is obviously important. Checking expiry, and then checking that the token was legitimately signed by the provider. This can be done by fetching and checking the token against the public set from the provider (which is discoverable through well-known/openid-config).

After this, we generate an issue a new Access Token and Refresh Token which the user can use to access resources on our API.

I haven't had to register a client ID or secret on the server, unlike with Authorization Code Flow.

I'm struggling to find good content of this kind of flow online. Is this technically know as Token Exchange since we're trading an 3rd party ID token with bearer access token? https://oauth.net/2/token-exchange/

What are the problems of this flow when compared to Authorization Code Flow. From what I can tell, if a user is revoked by the 3rd party provider, we wouldn't have any knowledge of that. UNLESS we also also keep the provider's refresh token, which we could use to check if the user has been revoked access.

Answer 1

PROPOSED SOLUTION

The security concerns in your proposed design are perhaps as follows:

• Does not involve the user, and personal data might be revealed without the user being informed
• Does not use the protections in standard OAuth protocol messages
• You issue tokens for your APIs based on tokens issued to other apps
• Bypasses security policies of the organizations running external identity providers (IDPs)

It is preferred to use the most standard and vetted options in security designs. In some setups, conversations with stakeholders are then much easier.

STANDARD FLOW

The usual way to manage this is for you as data owner to provide an authorization server (AS) that issues tokens to protect your data.

If required, logins can run a federated code flow with external IDPs, as described in my blog post.

In this flow the AS acts as a client of the external IDP. The IDP issues an ID token to the AS, and no tokens from other apps are used. The AS bootstraps a session after validating the ID token, then issues its own tokens.

SUMMARY

There is common ground in the standard flow and your proposal. Perhaps the main difference is that the standard flow is an official integration between conpanies. It would involve all of the right reviews, eg from identity teams. In some setups this might be more important than others.