Thursday, July 13, 2017

OAuth2 Notes

very hard to understand if you just check it from different web sources: people simply had wrong understanding or assumption on it.

OAuth:
it is not authentication nor authorization, it is about delegation protocol that is scalable.
I delegate access to someone to do something for me.

Client id: client should be registered with oauth server the first. along its id, usually there is a redirect_uri.
redirect_uri: is uased to verify the request is valid, and used to send authentication code back if the app is a web application.

access token: like session. used for secured api calls
refresh token: like a password to get new access token.

by reference token: reference is stored somewhere, it will convert reference to by value token for accessing apis
by value token: token will full information.

bearer token: like cash, when you spend it, no body ask for identification
holder of key token: like credit card. asking for identification. not shared by other users.

id token is for client to build a meaningful session between its client app and server app.
access token is meant for apis.

four roles:

user/me, client/application, authorization server/oauth server, resource server/where api or data is

steps:typical scenario

--client asks authorization erver for accessing resources on resource server,
--authorization server says sure if user agreed. it redirect client to user login page
--user signs in authorizatoin to complete authorization. once the authenticcation is successful, authorization server issues an authentication code to client app via redirect_uri.
--client app uses authentication code, its clilent id, and secrect to ask for an access token.
--client app now uses access token to access resources owned by user/on behalf of user.
--resource server can call authorization server to check if the token is valid. usually it does not need to and it simply check if the signature is trustable.
--resource server then provides resources to client app if token is valid.

it usually works with openid. after user logging in, the authorization server also returns id token that contains information about the user.
client app(server end) uses this id token to build an user session between client app's client and server.

in microservice, let each service understand JWT. and pass around JWT when it needs to call out for other services.

ID token is JWT token, JWT can also be access token.

token can expire, usually a refresh token is given at same time for client app to renew access token.

about exchanging token.
https://www.youtube.com/watch?v=1ZX7554l8hY

token has access scope
access token can be in bearer header, query string or payload, depending on oauth provider.

Client:
confidential client: web server etc
public client: model app, javascript in useragent etc

grant type:
two legged:
client credentials: accessing own resources.
    you provie client id and client secret/password to get access token.
    usually used on server side since it is OK when you can hide the client secret in server side configuration or code.
 
resource owner credentials:
    this is user strongly trust client app, and give out its own user and password to client app.

implicit:usually in javascript code
    https://tools.ietf.org/html/rfc6749#section-4.2
    It is designed for applications that access APIs only while the user is present at the application
 
    client app directs user to auth server to express authentication
    oauth server redirect res owner back to client app along with access token
    client app uses access token to access res user's resources on behalf of user
    it does not have refresh token since the client app is not authenticated.it was driven directly by user himself.
    (authentication code is for server that is proxy of user.)
    since access token is viewiable to user on same computer, it's required to be passed only within secured transport.
 
redirect_uri is defined as part of client login in oauth server, it includes redirect_uri as optional configuration. redirect_uri is
a mean of verification in implicit grant, not a mean of communication. but it is mean of communication in authentication code grant.
 
 
 
three-legged:
    authentication code: accessing other's resources