1B/ OAuth 101 / Vittorio

Session 1B

OAuth 101 - an IIW 101 Session

Session Convener: Vittorio

Notes-taker(s):

Tags / links to resources / technology discussed, related to this session:

• Goal — to help absolute beginners to learn about OAuth2.
• The session will discuss terminology, common scenarios, framework, etc.
• The session will not discuss Centralized/Decentralized Identity or SSI.
• Comments on SSI: SSI products are likely to be successful if they are built upon existing technologies.

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

NOTES FROM IIW #33 Session led by Vittorio

Scenario 1: Naive Approach

• A user signs in to Linkedin
• Linkedin asks a user to send invitations to all of users’ contacts via their gmail.
• User sends their gmail login credential to Linkedin so that Linkedin can send emails on the user’s behalf
• This naive approach is problematic as Linkedin will get unlimited access to the user’s account

Scenario 2: OAuth 2 Approach (Delegated Authorization)

• Linkedin is registered to the Authorization Server
• Linkedin writes an authorization message to the Authorization Server, asking to send emails for the user
• User’s gmail login credential is sent (correctly) to the Gmail server (Resource Server)
• Authorization Server then send a Consent Dialogue to the user asking for the user’s permission to perform the request
• If the user consent, the <authz code> will be sent to Linkedin
• Linkedin then sent <authz code> to the authorization server to obtain an access token
• Linkedin sends the access token to Gmail. Gmail will only allow Linkedin to perform the task as specified in the access token and nothing else. Hence, *Linkedin will be able to perform only the task that the user consented.

Comments on standards

• Conventional standards arise from pre-existing technologies where lots of people use similar approaches to solve the same problem. Then, these people come together to write a standard.
• Nowadays, some standards arise from non-existing nice-to-have technologies.

Note

• OAuth is not a layer where identity federation occurs.
• Other applications/standards are built on top on OAuth to provide identity federation