Home > Software design >  Use case of openID
Use case of openID

Time:12-15

I am a bit confused about the use case of openID.

say, if a user login to a web application using openID. Should this web application create an account for the user?

1). if it should, then what is the difference between using openID and using OAuth (set scope to "profile") to get the information of the user and then create an account for the user. (later login can use unique key from profile/id token to find the user in database)

2). if it shouldn't, then if the user logout, and then login using openID again, all the activity the user previously did (for instance, saved some article for later reading) has gone (assume no cookie/session is set, since they are limited to one device). if so, what is the point of authentication under this scenario

I understand openID is an extension of OAuth, specifically designed for authentication, but when and how should I use openID for authentication?

thanks

CodePudding user response:

OpenID is indeed an OAuth extension but it might be confusing,

OAuth2.0 : Authorization

OpenID Connect : Authentication

if you do all the authentication on your side, use OpenID Connect, if you only need to authorize you can use OAuth2.0 (if you have an already existing way of authenticating like SAML 2.0).

OpenID Connect add the JWT token that is standard for authentication (ID token). Remember that they are both standards, so you should follow it by reading the corresponding documentations.

You could use OAuth2.0 alone to do the authentication but it's not supposed to be like that and you would probably be out of the standard.

Similar question see : What's the difference between OpenID and OAuth?

CodePudding user response:

As EmCode pointed out OAuth is meant for authorization, OpenID Connect is meant for authentication. This means that using an OAuth flow, eventually you get an access token which let's you access a user's resources (or perform actions as that user). When using an OIDC flow you get an ID token which tells you who the user is. Of course you can mix both and get an ID token and an access token as a result of an OIDC flow.

For example:

You have an app which uses Google as the IdP for an OIDC login flow. When the user clicks the login button, they confirm identity at Google, and your app gets back an ID token. This token does not allow your app to access any of the user's resources controlled by Google (mail, calendar, photos, etc.). It just gives you information who the user is - maybe their name, email address, age, etc. based on what you requested with scopes.

If you used an OAuth flow, and asked the user to allow your app to access their calendar, then you would get an access token from Google. With this token you could call the Google calendar API to get the user's events, etc.

Once you have an ID token from an IdP, what you would usually do is to create an account in your app and connect it with the identity you got from the IdP. This allows you to save any relevant state/business data about your user. What OIDC gives you is that the user doesn't have to enter any passwords when logging in to your site - they can log in using Google, and your app will still know who the user is.

  • Related