1B/ IIW 101 Session OAuth

From IIW

IIW 101 Session-All About OAuth2


Session Convener: Vittorio Bertocci

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:

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


DIAGRAM: See image(s) for these notes in the IIWXXXIV Book of Proceedings here:

https://internetidentityworkshop.com/past-workshops/


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.


DIAGRAM


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


DIAGRAM

Retrieved from "https://iiw.identitycommons.net/index.php?title=1B/_IIW_101_Session_OAuth&oldid=24384"