-
Notifications
You must be signed in to change notification settings - Fork 5
OAuth
Jake edited this page Apr 29, 2014
·
15 revisions
- Client begins with "Log-in with -----" button
- Client then generates a cross-site request forgery (CSRF) token
- Hash generated by signing some session state variables with a secret key
- The end-user is redirected to ------ where they login
- ------ passes back to the clients redirect URI:
- CSRF
- exchange code
- Client then verifies the CSRF is the same
- Client sends the exchange code to ------ in a POST request
- ---- returns:
- Access token - to access user info
- ID token - to verify user identity (JWT)
- Refresh token - long story I'll tell later
The ----- could be our own OAuth server
- Voldemort DB? or Raik. (key-value store)
- Client passes to Auth Server
- Access token
- ID token (unique ID)
- Refresh token
- Client API Key
- convert POST to json_t
- Auth server Authenticates ID token
- Auth Server checks Database for ID Token & returns end-user ID
- or creates a new end-user & creates ID
- Auth Server updates Access Token in Database
- Auth Server Creates a Unique Access Token from hashing:
- Time Bucket
- End-User ID
- Server Secret Password
- Auth Server passes back to client the new Access Token/end-user ID
- HTTP: json getUser(access_token, id_token);
- game access token
- game client ID
- static/public
- string CreateAccessToken(end-user_ID, Server_Secret_Password);
- bool AuthenticateJWT(JWT, Client_API_KEY);
- bool AuthenticateAccessToken(Access_Token, end-user_ID, Server_Secret_Password);
- bool compareCSRF(sessionCSRF, returnedCSRF);
- string generateCSRF(string ... );
- json refreshUser(game access_token, game client_ID);
- new game access token
- same game client ID
- needs to check that passed access token is in current or last time bucket
- Jake