1

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 ?

Johan
  • 491
  • 5
  • 16
  • Related: [*What are the pieces of information delivered in a user profile at the end of a OpenID Connect flow?*](https://security.stackexchange.com/q/198952/21184) – Basil Bourque Dec 03 '18 at 00:53

2 Answers2

2

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

aviv
  • 1,267
  • 7
  • 8
  • OpenID 2.0 and OpenID Connect are quite different. OpenID Connect is built on top of OAuth 2. – paj28 Jan 21 '15 at 17:05
  • you are right, I was under the impression that the API is similar and the migration between 2.0 to connect was simple, but it turns out to be quite different. – aviv Jan 22 '15 at 13:21
  • 1
    from the open id FAQ about differences between 2.0 and connect: OpenID 2.0 used XML and a custom message signature scheme that in practice sometimes proved difficult for developers to get right, with the effect that OpenID 2.0 implementations would sometimes mysteriously refuse to interoperate. OAuth 2.0, the substrate for OpenID Connect, outsources the necessary encryption to the Web’s built-in TLS infrastructure, which is universally implemented on both client and server platforms. OpenID Connect uses standard JSON Web Token (JWT) data structures when signatures are required – aviv Jan 22 '15 at 13:23
  • Regarding *OpenID Connect* versus *OAuth2*, I found this YouTube video presentation quite helpful: [*OAuth 2.0 and OpenID Connect (in plain English)*](https://youtu.be/996OiexHze0) by Nate Barbettini. – Basil Bourque Dec 03 '18 at 00:57
0

In the end I chose not to use any form of OpenID (nor oauth not any of its friends)

In my project depending on openID providers introduced an invalid security setup. The principle is that no system should depend on another system for security where the other system has a lower or unknown security level guarantee than that required by the system.

While OpenID in principle is good, the implementation is left to the providers and there is essentially no guarantees.

JWT on its own proved to offer what was needed: a) Get rid of storing user secrets by using the principle of "Something you Have" as opposed to the common use of "Something you Know" (in the form of a password) as an authentication means. This proved to have additional benefits by making the server "stateless" and more performant by eliminating lookups on large user tables. b) Maintaining client-side sessions further gets rid of server-side maintained sessions. c) Allowing for a method of refreshing tokens using an attribute that is not itself stored in the token increases the security (Eg a malicious party needs both the username AND an existing valid token to be able to renew any token).

Aside / FWIW: When I asked this question 3 years ago very little was available on the Web on this topic.

Johan
  • 491
  • 5
  • 16