What information do you have to keep about a user to be an OpenID consumer? I wa

Question

What information do you have to keep about a user to be an OpenID consumer?

I want to use OpenID to let users register and authenticate on my system. So while I'm at it I want to not duplicate effort, and eliminate unnecessary passwords, etc from being stored.

I assume that besides the user's Profile details, you would need to store a copy of the user's Authentication/ID token from the ID provider as well as the user's ID URI, and a recovery email address in case the ID provider becomes inaccessible or the user wants to link a new ID provider to their account on your system. It also appears that there is a temporary "request" Token used during sign-up and/or during re-authentication, but this is short lived and used once only, so may not need to be stored in the database ever.

Does different ID providers, eg Facebook, Twitter, LinkedIn, Google Connect all provide similar enough authentication tokens that I can simply call the database columns something like "IDProviderToken" and "IDProviderURI", or do I need data specific to Facebook/Google/etc ?

Explanation / Answer

What you keep about the user is your own decision. The most basic implementation is keeping a user ID (the one received from the open ID provider) and the token you receive from the open ID provider (which includes access token, expiration and refresh token). whatever you wish to keep beyond that is up to you.

As much as I know every openid connect provider must respond with the same data structure... that is part of the protocol, but openid has three versions: 1.0, 2.0 and connect

Some examples of providers: Google and Microsoft Azure now use openid connect for their openid services. Yahoo uses openid 2.0 You mentioned Facebook - they are not an openid provider, they have their own unique protocol

Related Questions

Navigate

• Browse (All)
• Browse W
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.