password leaving the site where the protected data is. Short-lived tokens in lieu of passwords to access information. A standard that works across all the API access patterns.
commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords. (Wikipedia) OAuth 2.0 relies on HTTP over TLS OAuth is an authorization protocol, and NOT an authentication protocol. * I still have bad dreams about OAuth 1.0 and 1.0a
(data) exists on a Resource Server. The Resource Owner grants access to a Client to access these resources, by authorizing access to those resources on an Authorization Server where his identity exists and can be authenticated. The Client then gets credentials from the Authorization Server that can be used on the Resource Owner’s behalf to access the resources on the Resource Server.
behalf MyFitnessPal getting your Step Count from your Fitbit Account Turbotax getting your trades from your Fidelity Account Instacart Servers calling Marqeta’s API Facebook iOS app accessing your Facebook account Single Page App (RCA) accessing your News Aggregator
the client using the access token. Scopes can be sliced and diced in many ways - Read vs. Write, Functionality based, Default, etc. Be careful defining them - you’ll end up with an LDAP ACLs. Scopes <> ACL.
owner to the authorization server by passing in the response_type=code, redirect_uri, scope, and client_id. 2. The authorization server asks the resource owner for his credentials, MFA may be performed here. 3. The authorization server asks the resource owner to pick scopes that the client will be authorized for. 4. Upon the resource owner granting access, the authorization server sends a short lived authorization code to the redirect_uri 5. The client uses this authorization code to do a POST on the authorization server, passing in client_id, client_secret, and grant_type=authorization_code. 6. The client receives a refresh token and and access token.
Browser Extensions.. There is no client_secret since the client cannot keep the secret. A simplified version of Authorization Code Grant. A refresh token is not returned in the response. Never, ever used in Financial Systems.
the authorization URL same as Authorization Code Flow, except response_type is token (vs. code), and grant_type is not passed. 2. Upon the access being granted by the resource owner, an Access Token is provided to the client.
Mobile Apps provided by the Resource Server who is also the Identity Server. The only grant type where a user’s credentials are passed in the token request. Also known as Password Grant
the Authorization server as a POST with grant_type=password, client_id, client_secret, scope, username, and password. 2. The Authorization Server responds with an access token and a refresh token.
machine, or service to service call. There is no identity involved. Also known as 2-legged OAuth. A refresh token is not returned. Simplest of all grant types. Additional security via whitelisting and firewalling can be implemented.
to the authorization server with client_id, client_secret, grant_type=client_credentials and scope. 2. Authorization server returns an access token to the client.