OpenID Connect use case

jwt, openid-connect

Solution

I would agree with you that the most interesting aspect of these modern authentication schemes is that you easily delegate authentication to a third-party provider and not be burdened with having to write and support all that boilerplate, but highly sensitive code around managing user identities.

In relation to your, what happens next questions lets approach them one by one; I'll try not to start every answer with it depends.

Q1Shall I still have a local user DB (without password) populated from these fields?

It depends, if your application does not need to know about user information when the user is not online interacting with the application then you can get away with almost not having to store anything. At most you want to store a unique user identifier to data that the user creates.

On the other hand, if your application notifies the user by email when something (really) interesting happens then you need to store the user email on your database.

Q2(If I need to duplicate almost all the information in my database is) OpenID Connect just a fancy automatic sign-up procedure?

Kind of, just by being a standard that allows you to delegate your application authentication to a third-party you already gained massive benefits from its existence. Authentication is not trivial, if you can offload that to someone else, do it. By doing this you're also doing the end user a favor, because (depending on the popularity of the provider you choose) he can now login into your application without having to remember yet another set of credentials.

Q3What about sessions and log-outs?

Here there are no substantial changes if you want an independent session. Before your application would validate credentials and start a session, now it will validate a token that might be provided by a third-party and then start a session. Logout would just end your session.

If you want a synced session, so that the user is only active in your application while he also has a session in the third-party provider then you have more work to do. See, if you haven't done it already, OpenID Connect Session Management 1.0 for more information.

Q4What if user changes his phone on the Google site while I still have it saved the old version?

That's a non issue, because if you were not using OpenID Connect and had to manage application-specific user identities, you would have the same problem. The user would change their phone on Google and unless he also proactively changed the phone in your app it would be outdated.

As fiddur pointed out, there's also the possibility of proactively checking with the provider if there's updated information. This is something that most provider support and has the side-benefit that can also provide a good user experience for the end user.

In conclusion, if you have the opportunity to delegate authentication to an external provider please do so. Implementing your own custom authentication or even establishing yourself as an authentication provider complying with all the available standards is a very time consuming challenge, riddled with security pitfalls.

If you are thinking that you need to have better control of the authentication process than what a social authentication provider would give you, there's still the option of going with a more flexible provider, Auth0 comes to mind, but I'm biased ( I'm an Auth0 engineer ). This type of option will give you more control while still taking the burden of implementing authentication standards of your back.

Problem

Original source