I am trying to understand how to add social login and registration to a service. After reading many blogs posts, many reminding me of the pitfalls of designing such a system, of the fact that Oauth is for Authorization not Authentication, most written by people exploring this topic as they write, all with different opinions on what OpenID/OpenID connect/etc is all about, I am finding myself more confused than before I started.
My understanding is that with Social Login the ID-provider does the Authentication. When the user is authenticated, the client (or the user agent) must be in possession of something (a secure token?) that indicates that the user managed to prove their identity. On subsequent requests to /the/ API, the server, which from the point of view of the ID provider is a 3rd party (called a relying party in some documents?) would need to be able to verify this "token" and needs to be able to derive from this "token" who the actual user is.
So, in practical terms:
- What would the API receive from the client when a user signed in using with Social Login?
- What would the API receive from the client when a user registers with Social Login?
- As a minimum what do I need to store about each user for authentication purpose (User-ID? Email for recovery/linking multiple accounts? ID-provider (in what format?), List of current sessions/expiry dates? Last access/update time maybe? What else?)
The current system (a REST-full API) issues a token when the user signs in with email/password with a post to
api.example.com/session. In this case the API is able to check that the user supplied the correct credentials.
I gather that many articles online talk only about how to use the tokens to consume the resources provided by that same organisation, eg Facebook login for consuming Facebook APIs. This might just be my misunderstanding though.
Some specific questions:
- What does this token look like? Does it reveal the Identity Provider or how to verify the validity of the Token?
- Does the token give the relying party (The API backend servers) a way to obtain, say for example the user's Full Name or Email Address? Or would that be functionality delegated to the Client?
- Who determines what information this Token provides - The ID provider or the client application?
- What about the case of a Web client where the client and user-agent is not running on the same device? Can the client or user agent "build" a new token which can be used to sign requests to the API, and include the important details (User-ID, ID-provider, expiry date, client-ID)?
- Can the API "session" endpoint be extended to handle "social login" tokens or is that not the correct approach?
- Is it important to Identify / Authenticate the Client? If so how - I believe mobile clients cannot securely store a signing key!?
A note about oAuth and Authorization: I don't think I need authorisation here. The API already determines whether requests are authorised based on the identified user.