OAuth 2 is the latest version of the OAuth standard– unlocking authorized access to user data from dozens of different APIs like YouTube, Google Apps and Facebook in a way that’s easier than ever for developers. OAuth 2 can now be used via OpenID Connect to allow users to easily login and sign up with apps faster, with less developer effort.
This session will cover how web and mobile applications can take advantage of this technology to improve the experience and security of user accounts.
Presenters
Resources
Notes
OAuth 2 is an authorization (delegated authorization) protocol. Prior to OAuth type protocols, you had to share your passwords with apps so they could access other apps (POP3 anyone?). OAuth eliminates the need for this, allows you to restrict the level of access you grant an app. Helps reduce the issue of “using the same username/password on multiple sites”. Helps optimize an on-board workflow (shorten the sign-up process).
- Authentication
- verifying the identity of a user — they are who they say they are. process: saying that a password is the correct one for this username.
- Authorization
- what data a user has access to, and what actions/operations they are allowed to perform
OpenID Connect is built on OAuth 2.0.
Seeking balance between security and usability is a constant battle. If security reduces usability too far, people fail to adopt the security protocol you wanted them to in the first place.
RFC 6749/6750: OAuth 2 is a framework not a specification.
Common goal: acquire an access token that allows you to make a request to an API
Acquisition
Involves developer registration (identify your API, get a client id and a client secret)
Client-side flow (JS)
- Uses a hash fragment (anchor) to pass the token instead of query parameter so it is less likely to be logged
- requires user to stay logged into the central auth api for renewal to happen seamlessly.
- there is no common sign-out at this time
- POST message flow immediate OAuth
Server-side flow (Authorization Code) (Python)
- Uses an intermediate authorization code as a query parameter for the back-end exchange to get an access token
- can get long-lived “refresh token” to renew access without user interaction (refresh token is stored; keep tokens stored separately from client secret)
Other flows
- resource owner password credential flows (like old ClientLogin)
- app-based authorization (not single user based, but entire app needs broad user access; client id/client secret as username/password; Google supports JSON Web Token assertion, adds crypt to token request)
Access
Calling the api: pass an HTTP header (Authorization) or use Query parameter; HTTP best since not logged by default. query parameter is more for debugging
Scopes (json/query parameters): authz for multiple APIs at once (space delimited list for google, comma delimited for facebook)
Mobile
- Embedded WebViews
- (cross-platform)
- authorization flow happens within an embedded window: there’s no pop-up, but doesn’t use the same cookie store so there is no “session detecting”. credentials exposed to native app because it is “wrapped” not redirected.
- System web browser
- (cross-platform)
- pops out of native app into system browser, uses common cookies. acts like a pop-up/context switch, and creates the problem of getting back to the native app (interceptions).
- GoogleAuthUtil
- (Android-specific client)
- Google does the flow mediation in a signed/secure manner
OpenID Connect OAuth 2.0 for Log-in
Streamline registration of new account profiles (asks your auth center for the info and pre-fills). Grants a secure, central, unique identifier. Uses scopes to get access to the rest of the profile info. There’s an official G+ log-in button (Google+ Sign-In): desktop and mobile versions (with option to install related android app and authz in one step)
Controversy
Eran’s Concerns:
- if it’s done RIGHT, you can implement it well. but it’s not a spec, so it can be done horribly, horribly wrong.
- bearer tokens are bad (eliminates a layer of security in favor of SSL/TLS, vulnerable to developers not validating cert chains); cryptographic signatures are important
- expiring tokens are twice as painful as cryptographic signatures (but more useful for debugging)