An overview of OAuth 2.0 and OpenID Connect. How they are related and how they fit into the Neo Security Stack.

1. OAuth 2.0 and OpenID Connect
Jacob Combs

2. What are we going to cover today?
1) Neo Security Stack
2) OAuth 2.0
3) OpenID Connect

3. Neo Security Stack
Authentication U2F, Yubikey
Provisioning SCIM
Identities JSON Identity Suite
Federation OpenID Connect
Delegated Access Oauth 2
Authorization ALFA
Built upon open standards.

4. OAuth 2.0
OAuth 2.0 is the industry-standard protocol for authorization.
● Delegated access
● No password sharing
● Revocation of access
Oauth 2 is a protocol of protocols and used as a base for other
specifications:
● OpenID Connect
● UMA
● IndieAuth
Improper usage of Oauth
● Not for authentication
● Not for federation
● Not really for authorization

5. OAuth 2.0 In Practice

6. OAuth 2.0 Actors
● Resource Owner (The User)
○ The resource owner is the person who is
giving access to some portion of their
account.
● Resource Server (The API)
○ The API server used to access the user's
information.
● Client (3rd Party Application)
○ The application that is attempting to get
access to the user's account. It needs to get
permission from the user before it can do so.
● Authorization Server:
○ The server that presents the interface where
the user approves or denies the request.

7. Tokens
● OAuth 2.0 allows for multiple types of
tokens to be used.
○ WS-Security
○ SAML
○ Custom
○ JWT: JSON Web Tokens (pronounced JOT)
■ Lightweight tokens passed in HTTP
headers & query strings
■ Similar to SAML (Less security
options and more compact)
● Kinds of Token
○ Access Tokens
■ The access token represents the
authorization of a specific
application to access specific
parts of a user’s data.
○ Refresh Tokens
■ Used to get new Access Tokens
○ Bearer Tokens
■ a single string which acts as the
authentication of the API
request
■ Must use HTTPS

8. Scopes
The permissions represented by the Access Token in OAuth 2.0 terms are known as
scopes.
You can use scopes to:
● Let an application verify the identity of a user (by using OpenID Connect) and
get basic profile information about the user, such as their email or picture.
● Implement granular access control to your API by defining custom scopes for
your API.

9. Google Scope Example

10. Authorization Grant Types - Authorization Code
Before the authorization server issues an
access token, the app must first receive an
authorization code from the resource server.
Sometimes called "three-legged" Oauth.
When you app opens a browser and invites
you to login to your actual account.
Most secure method of auth.

11. Authorization Grant Types - Implicit
The authorization server returns an
access code directly when the user is
authenticated, rather than issuing an
authorization code first.
Typically used when the app resides
on the client. Code is implemented in
the browser (JavaScript) instead of
running on a separate web server.

12. Authorization Grant Types - Resource Owner Credentials
“Password”
Access token is issued when the
user's username/password are
validated by the authorization
server.
User/pass is only presented
once, from then on the access
token is used.

13. Authorization Grant Types - Client Credentials
Client app is acting on its
own behalf. Provides client
ID and client secret to be
issued an access token.

14. Authorization Grant Types - JSON Web Token
JWT for OAuth Client Authorization Grants
enables a client to send a signed JWT token to
the OpenID Connect Provider in exchange for
an OAuth 2.0 access token.

15. OpenID Connect
(Identity, Authentication) + OAuth 2.0 = OpenID Connect
A Protocol used to authenticate users of an application, and
represent those users in a standard way.

16. Components of OpenID Connect
● Access Token
○ Credentials that can be used by an application to access an API.
● ID Token
○ A JSON Web Token (JWT) that contains identity data. It is consumed by the application and used
to get user information.
● Claims
○ Statements (such as name or email address) about an entity (typically, the user) and additional
metadata. The set of standard claims include name, email, gender, birth date, and so on.

17. Facebook has similar implementation
Signed request
Uses Facebook as the Identity Provider
Proprietary signature format - Only works with
Facebook
ID Token
Works with multiple Identity Providers
Standard IETF JSON Web Signature

18. Implicit Flow
The Implicit flow is required for apps and
websites that have no back end logic on the
web server.
Everything that is passed between the app or
site and the IdP can be viewed using browser
development tools.

19. Authentication (Basic) Flow
The Authentication (or Basic) flow is an
option for apps that have web-server
logic that enables back-end
communication with the Identity
Provider.
In this flow, rather than transmit the
user details, the provider sends a special,
one-time-use code that can be
exchanged by the back-end web service
for an OAuth access token.

20. Demo of OpenID Connect Workflow
https://openidconnect.net/

21. Resources
OAuth 2.0 - https://oauth.net/2/
OAuth 2.0 Simplified - https://aaronparecki.com/oauth-2-simplified/
OpenID Website - https://openid.net
Google Use of OpenID Connect - https://developers.google.com/identity/protocols/OpenIDConnect
OneLogin and OpenID Connect - https://developers.onelogin.com/openid-connect
Auth0 Webinar - https://auth0.com/resources/webinars/intro-openid-connect