DevTeach Montreal 2017 Talk on OAuth and OpenId Connect, how the technology works the communication channels used and the different kind of grants in OAuth and how OpenId Connect plays in the entire ecosystem
2. WHO AM I??
- 4 years Microsoft MVP
- 17 years in software
- Author of Instant Automapper (Packt)
- Currently working at as System Architect at Enterprise Security
Space (Gemalto)
- You may not have heard of Gemalto but 1/3 of the world population
uses Gemalto but they just dont know that
3. WHAT WE WILL COVER TODAY?
OAuth 2.0
OAuth flows
OpenID
JWT (JavaScript Web Token) some says “jot”
OpenID Connect
Demo (Keycloak IDP)
4. WHAT IS OAUTH?
An open protocol to allow secure authorization in a simple and
standard method from web, mobile and desktop applications.
5. OAUTH HISTORY
OAuth started circa 2007
2010 - RFC 5849 defines OAuth 1.0
2010 - OAuth 2.0 work begins in IETF
Working deployments of various drafts & versions at Google,
Microsoft, Facebook, Github , Twitter, Flickr, Dropbox …
Mid 2012 – Lead author and editor resigned & withdraws his name
from all specs (DRAMA……)
October 2012 – RFC 6749, RFC 6750
6. THE GOOD
OAuth 2.0 is easier to implement than OAuth 1.0
Wide spread and continue growing
Shorted lived token
Encapsulated Token
OAuth2 makes it HTTP/JSON friendly to request and transmit tokens
Takes "multiple client" architectures into account
Clients can have varying trust levels
7. OAUTH 2.0
- Transport Security : Using HTTPS and TLS
- Ease : Usable (no digital certs to verify)
- Flexible : Mobile, Web SPA apps, etc
- Decoupled: Resource server and authorization server
- Bearer Token : Easy for integration; Id Token also known as keys
9/24/2017 7
12. OAUTH MISCONCEPTION
Ohh this is easy!! When I login to
Spotify with Twitter, it grabs by
username and password from
Twitter….
Wrong
!!!!!!!!!!!!!!
9/24/2017 12
Developer
13. OAUTH IS NOT FOR
9/24/2017 13
- Traditional Access Control
- Not for authentication
- Not for Federation
- OAuth should be used for delegation
14. BEARER TOKEN
GET /somedata HTTP/1.1
Host: someserver.com
Authorization: Bearer a3b4c55cf
The access token can be JWT
format
- A security token with the
property that any party in
possession of the token (a
"bearer") can use the token in
any way that any other party in
possession of it can
9/24/2017 14
15. OAUTH TERMINOLOGY
- Client or Consumer Application : Is typically a web based
or mobile application that wants to access User’s Protected
Resources
- Resource Server or the Resource Provider: Is a web site or
web service API where the User keeps his/her protected
data
- Authorized Server : The server issuing access tokens to
the client after successfully authenticating the resources
and obtaining authorization
- User or the Resource Owner : Is a member of the Resource
Provider, wanting to share certain resources with a third
party
- Client Credentials : Are the consumer keys and consumer
secret used to authenticated the Client
- Tokens : are the access token generated by server after
request from client
16. OAUTH TOKEN TYPES
- Access Token : Used to directly access protected resources on
behalf of a user or service
- Refresh Token : When given to an authorization server, it will give
you a new access token
- Authorization Code Token : Use only in the authorization code
grant type for access token or refresh token
9/24/2017 16
17. HIGH LEVEL FLOW OF OAUTH 2
- An app registers him/herself on an oauth service provider (lets say
twitter)
- S/he gets an app key/secret for each app that s/he registers
- When users login they are redirected to the service provider to
provide the credentials
- If user approves then a token is issued to the app for a limited time
- Finally the client uses the token to access the resource
18. OAUTH USAGE
In OAuth [authorization]
You are in BigPhotoPrintingCorp.net account and you need to access your
images from AwesomeImage.com site
BigPhotoPrintingCorp.net site will redirect you to AwesomeImage.com site
You enter you credential to AwesomeImage.com site and authenticated your
self. This is like in openId
AwesomeImage.com site will ask if you want to give permission to access
only photos of AwesomeImage.com site
you select yes
AwesomeImage.com site will redirect back to BigPhotoPrintingCorp.net site
BigPhotoPrintingCorp.net can access AwesomeImage.com site
20. 4 TYPES OF OAUTH FLOW
Authorization Code Grant : for apps running on a web server, long
lived tokens
Implicit Grant : For browser-based or mobile apps, during user is
logged in, short lived tokens
Resource Owner Credentials Grant : For logging in with a username
and password, trusted application
Client credentials Grant : for application access machine to machine
21. AUTHORIZATION CODE FOR APPS
RUNNING ON A WEB SERVER
This is the most common type of application you have when dealing
with OAuth servers.
Web apps are run on a server where the source code of the
application is not available to the public.
This case your site will REDIRECT you to particular authorization
server. If webserver making multiple request it can use STATE
parameter for map callback response with request
One of the most complicated one in OAuth
23. IMPLICIT FOR BROWSER-BASED OR
MOBILE APPS
Browser-based apps run entirely in the browser after getting source
code from a web server. Since the entire source code is available to
the public, they cannot maintain the confidentiality of their client
secret, so the secret is not used in this case
One will make api calls with the token that is assign to it
For mobile apps also cannot maintain the confidentiality of their
client secret. Because of this, mobile apps must also use an OAuth
flow that does not require a client secret. With this concept token is
exposed to local operating system. So there are no refresh tokens.
24. PASSWORD FOR LOGGING IN WITH A
USERNAME AND PASSWORD
OAuth 2 also provides a “password” grant type which can be used to
exchange a username and password for an access token directly.
This obviously requires the application to collect the user’s password.
As a result users may hesitate to use this service unless this app
comes from the auth service provider.
Only used in highly trusted application, your social media Facebook
app, rather than 3rd party apps (Batman Fancy Facebook app)
25. MEET THE ACTORS IN OUR OAUTH
9/24/2017 25
Resource Owner
Or User
Application Authorization Server Resource Server
Or API
26. CLIENT CREDENTIALS FOR
APPLICATION ACCESS
There are scenarios that applications may wish to get statistics about
the users of the app.
In this case, applications need a way to get an access token for their
own account, outside the context of any specific user.
OAuth provides the client credentials grant type for this purpose.
This is machine to machine communication sort of concept
32. SCOPES AKA PERMISSIONS
- Roles, Authority where you want to give access control to who can
do what with it
- The name of permissions
- User scopes
- Client/Applications Scopes
- Token contains intersection
9/24/2017 32
37. AUTHORIZATION GRANT
$ https://fancy.mysite.com/oidc #Reaching out to application, are
you logged in?
302 HTTP Redirect
https://api.mysite.com/authorize?response_type=code&client_id=Te
stClient&redirect_uri=https://fancy.mysite.com/oidc
9/24/2017 37
38. AUTHORIZATION CODE GRANT
GET /oauth/authorize #Login to the app
SUCCESS you get back a code
HTTP 302 redirect back to redirect_uri
https://fancy.mysite.com/oidc?code=SplxlOBeZQQYbYS6WxSbIA&stat
e=xyz
9/24/2017 38
40. ACCESS TOKEN
Response from Authorization Server
{
"access_token":"03807cb390319329bdf6c777d4dfae9c0d3b3c35",
"expires_in":3600,“
token_type":"bearer",
"scope": “CarKey.Ignite”
}
9/24/2017 40
41. RESOURCE SERVER CHECK TOKEN
- If it is a Jwt token you can verify the key who signed it
- Endpoint to check the token returning the scopes to verify if valid
token
9/24/2017 41
42. IMPLICT GRANT TYPE
- Used for clients that can easily be impersonated like phone or
mobile application
- 3rd party application
- A simplified Authorization Code Grant with eliminating the code
step
- Access token is given directly to the app
- No Refresh Token are given, Access token are short lived
- Requires Resource Owner to invoke for new Access Token
9/24/2017 42
44. OPENID
Sharing a single Identity with different consumers
Decentralized
OpenID is a form of Single Sign On (SSO)
OpenID is a URL http://myname.myopenid.com
45. WHAT CAN YOU DO?
One can claim and prove they own the openid
Use it for authentication
At a high level its like Microsoft Passport
It’s a form of authentication, if you have a system you still will need
to populate your fields (e.g firstname, email, etc)
OpenId does not provide you with those information
46. OPENID USAGE
In OpenId [authentication]
You want to access your account on bigcorp.net
bigcorp.net is asking your openId
You entered your username for openId
bigcorp.net will redirect you to the your openid providers site
User give password to openId provider and authenticate him/her self
openId provider will redirect user back to bigcorp.net site
bigcorp.net will grant you to access your account
47. OPENID CONNECT
We have talked about OAuth and OpenId and there is also OpenId
Connect
It’s the new SSO authentication for the internet
OpenId Connect build on top of OAuth2 since sometimes you may
just need authentication
Remember OAuth2 is for authorization
OpenID Connect provides
Implict flows and Authorization code flow
51. JWT (JAVA WEB TOKEN)
JSON Web Token (JWT) is a compact URL-safe means of representing
claims to be transferred between two parties.
The claims in a JWT are encoded as a JavaScript Object Notation
(JSON) object that is used as the payload of a JSON Web Signature
(JWS) structure or as the plaintext of a JSON Web Encryption (JWE)
structure, enabling the claims to be digitally signed or MACed and/or
encrypted.
52. JWT CONT
JWT Token looks like this
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjEzODY4OTkxMzEsI
mlzcyI6ImppcmE6MTU0ODk1OTUiLCJxc2giOiI4MDYzZmY0Y2ExZTQx
ZGY3YmM5MGM4YWI2ZDBmNjIwN2Q0OTFjZjZkYWQ3YzY2ZWE3OTdi
NDYxNGI3MTkyMmU5IiwiaWF0IjoxMzg2ODk4OTUxfQ.uKqU9dTB6gK
wG6jQCuXYAiMNdfNRw98Hw_IWuA5MaMo
Ok great…………. Once you understand the format, it's actually pretty
simple:
<base64-encoded header>.<base64-encoded claims>.<base64-
encoded signature>
[header].[payload].[signature]
53. JWT CONT
In other words:
You create a header object, with the JSON format. Then you encode it
as a base64
You create a claims object, with the JSON format. Then you encode it
in base64
You create a signature for the URI. Then you encode it in base64
You concatenate the three items, with the "." separator
54. BENEFITS
JSON Web Tokens work across different programming languages:
JWTs work in .NET, Python, Node.js, Java, PHP, Ruby, Go, JavaScript,
and Haskell. So you can see that these can be used in many different
scenarios.
JWTs are self-contained: They will carry all the information necessary
within itself. This means that a JWT will be able to transmit basic
information about itself, a payload (usually user information), and a
signature.
JWTs can be passed around easily: Since JWTs are self-contained, they
are perfectly used inside an HTTP header when authenticating an API.
You can also pass it through the URL.
55. HEADER
The header carries 2 parts (JWT and the hashing algorithm like below)
{ “typ”: “JWT”. “algo”, “HS256” }
Then base64 encode it
56. PAYLOAD & CLAIMS
The payload will carry the bulk of our JWT, also called the JWT Claims. This is
where we will put the information that we want to transmit and other
information about our token.
There are multiple claims that we can provide. This includes registered claim
names, public claim names, and private claim names.
{
"iss": “taswar.zeytinsoft.com",
"exp": 1300819380,
"name": “Taswar Bhatti",
"admin": true
}
57. SIGNATURE
The third and final part of our JSON Web Token is going to be the
signature. This signature is made up of a hash of the following
components:
the header
the payload
Secret
The secret is the signature held by the server. This is the way that our
server will be able to verify existing tokens and sign new ones.
var encodedString = base64UrlEncode(header) + "." +
base64UrlEncode(payload);
HMACSHA256(encodedString, 'secret');
59. OPENID CONNECT TOKENS
The OpenID Connect server provides client applications with two
key tokens:
ID token - asserts the users identity in a signed and verifiable way.
Access token - provides access to the user’s details at the UserInfo
endpoint and other protected web APIs.