1

From what I understand about using OpenID Connect (over OAuth2), is that we end up with some JSON containing information about the user. That information is transported as a JSON Web Token.

➥ What are the pieces of information specifically?

  • User’s email?
  • User’s mobile phone number?
  • User's human name?
  • User’s “username” on some system?
  • Some kind of unique identifier?

Looking through the OpenID Connect site, such as this page, mysteriously I cannot find any explanation of the payload at the end of a OpenID Connect transaction.

If multiple pieces of private information are provided, is there a way to ask for authorization to provide only a subset such as email address but not phone number, just like granularities of scope in a OAuth2 request for delegated authorization?

Most of what little I know about OpenID Connect came from the video presentation, OAuth 2.0 and OpenID Connect (in plain English) by Nate Barbettini of Okta.com. He explains the mechanisms & protocols very well, but did not touch on the actual content/payload.

Basil Bourque
  • 137
  • 6
  • Related: [*Can I get rid of storing user secrets by using OpenID, and what do I need to store?*](https://security.stackexchange.com/q/79724/21184) – Basil Bourque Dec 03 '18 at 00:53

1 Answers1

1

You were almost at the right resource! If you click the core link on the page you referenced you'll find all the answers you're looking for.

There is a section on the ID token which contains the claims (attributes) that are defined by the OpenID connect spec. The only one that matches up to you list is the sub (subject) which is a unique identifier for the user.

So where are the rest?

The spec defines a set of standard claims that match up to the attributes you've mentioned. In fact, the ID Token is intended to be extensible. As such you can add whatever claims you like to the token.

Requesting access

The mechanism for adding various claims to the provided ID token is done (as you've suggested) using scopes. Most authentication servers allow the creation of rules that govern which claims are requested by each scope.

Andy N
  • 442
  • 3
  • 12