INTRO: Open ID Connect (101)

Intro to Open ID Connect

Tuesday 2G

Convener: George Fletcher, Don thibeau

Notes-taker(s):Garrett Schlesinger

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if

appropriate to this discussion: action items, next steps:

An identity/authentication layer on top of OAuth 2.0

Connection protocol suite

- Key piece: core spec (all bits of the protocol) which include implementation guides.

- Discovery & dynamic client registration are about making the pre-registration bit in OAuth

2.0 to become more dynamic. Important for IOT.

- Form post response mode: less important.

- Session management: more important. How do sessions end? How do you know a session is

still valid?

Session management:

- Front-channel logout (logout in the browser. Propagate to all relying parties.)

- Back-channel logout (logout all on server side. works if you have server-side sessions

everywhere)

See: http://openid.net/wg/connect/

Health relationship trust (Heart)

Internation assurance government profile

OpenID Certification

- Enables openid connect implementation to be certified for interoperability, etc.

Authentication

Definition: "how do we know it's you"

Web site wants to know who you are. Site redirects (OAuth 2) to one (or a selection amongst

several) IdPs (identity providers). Requires an opened scope. IdP will often first look for an SSO

token. Prompt for credentials otherwise. IdP prompts for consents ("Do you want to share your

email address?" etc). IdP redirects back with a code + state parameter (mitigates CSRF). Code is an

artifact (like in SAML) that is then used for then generating an access token via site's backend

calling to the IdP. IdP passes back id_token (possibly also access token and refresh token). Requires

client credentials in addition to the code. OpenID allows for several methods of authentication,

some using public key infrastructure (PKI) ,signed JWTs, client shared secrets, etc.

Flows: code, implicit, hybrid.

No value in secrets in the browser.

Implicit flow optimizes the code flow by shoving everything into the browser. Sends id token etc in

browser hash since the browser shouldn't persist this in history. Doesn't in practice work that well

on all browsers. In any case, really need to validate the id token. Look at the issuer. Validate their

public key. Who knows what could happen with MiM attacks, etc. Also need to check that the id

token was intended for you. Easy to mess this up, actually. Lots of big sites have gotten this wrong.

Hybrid flow-- in between the code flow and implicit flows.

ID tokens are assertions. A best practice would be to have something to inspect the tokens.

Authorization requires layering if we've learned anything from social media apps. Can't 100% split

out authentication as a result since we will need to come back to it for more scopes!

id_token (a JWT):

- iss: the IdP: who issued the token. introspect this to know what public key to look up to

validate the token, make sure it comes from where you think it did.

- sub: the user (subject)

- aud: audience (client): to whom the token was issued. possibly an array, but that's a detail.

- iat: issued-at time

- exp: when the token expires

- jti: unique id (possibly a uuid) for this token

JOSE spec. Signing mechanism. Encryption also possible.

JWT parts:

Header: {typ: JWT, alg: RS256, kid: pubkey1}: cryptographic envelope

Payload: (just has to be JSON): {"iss": "https://auth.blah....%22, "sub": "9X8FH2"}

Signature:

format: <b64-encoded header>.<b64-encoded payload>.<signature>

Signature is used to validate the header and payload. Dead simple. Validate the original b64-

encoding since generating your own could get mucked up with JSON key ordering.