4. 4
What is OAuth2?
• A protocol for conveying authorization decisions (via access token)
> It is NOT an authentication protocol
> Typically used with OpenID Connect
• Standard means of obtaining a token – there are four grant types
> Authorization code
> Resource owner password grant
> Implicit
> Client credentials
• Separation of client application from resource owner
> I, resource owner, authorize this app (client app) to perform these
actions on my behalf
5. 5
What is OAuth2 Not?
• It is NOT an authentication protocol
> The user must be authenticated to obtain a token
> How the user is authenticated is outside of the spec*
> How the token is validated is outside of the spec*
> What the token contains is outside of the spec*
• OpenID Connect handles authentication part
7. 7
Securing Monolithic App
• You only need to authenticate the request once per user
• If there has been no session
> Verify user credentials
> Start a user session
> Provide role-based access control
• Else (session is already created)
> Verify session has not expired
• Method calls are trusted
8. 8
Securing Monolithic App
• Pros
> Limited attack space
• Cons
> Once granted permission, the user has all the credentials for the rest of
the application including database access – once it is hacked, the whole
application is in danger
9. 9
OAuth2 Secures Micro Services
• Single sign on (SSO)
> SSO along the service call chain
• Stateless
> Backend services do not want to maintain user credentials
> Backend services do not want to maintain user sessions
• Delegated access (access some resource on behalf of me)
> A service can access a resource of another service on behalf of resource owner
• User credentials not exposed
> Only Identity server should manage user credentials
• Fine grained and flexible authorization
> Each service has different access control requirements
• Interoperability with non browser clients
> Browser, mobile devices, services
11. 11
Authorization Code Flow - Actors
• Actors
> Resource owner (user)
> Client web app
> Resource server
> Auth. server
• Use case
> Photo-sharing app (client)
wants to access user's friends
data from Facebook (resource
server)
client
web app
auth server
resource
server
12. 12
Authorization Code Flow – step 1
• User (Resource owner)
accesses the client web app for
the first time
client
web app
auth server
resource
server
13. 13
Authorization Code Flow – step 2
• Client redirects the request to
the “./oauth/authorize” endpoint
of the auth-server
• Note 1 – the client web app has
to be configured with endpoint
location of the
“./oauth/authorize” of the auth
server
• Note 2 – the client web app
redirects the request – in other
words, there is no direct
communication between client
and auth server yet
client
web app
auth server
resource
server
14. 14
Authorization Code Flow – step 3
• Auth server redirects the user to
its login page since the user
isn't logged in to the auth server
(this is an authentication)
• User logs in and is redirected
back to the “./oauth/authorize”
endpoint
client
web app
auth server
resource
server
15. 15
Authorization Code Flow – step 4
• User is then presented with “do
you approve for the client app
to perform some actions
specified in the scope?”
• User authorizes (or approve)
them
client
web app
auth server
resource
server
16. 16
Authorization Code Flow – step 5
• Auth server redirects the user
back to the client web app with
“authorization code” (in the
query params of the redirect)
client
web app
auth server
resource
server
17. 17
Authorization Code Flow – step 6
• Client web app accesses
“./oauth/token” endpoint of the
auth server with the
authorization code
• Note 1 – the client web app has
to be configured with endpoint
location of the “./oauth/token” of
the auth server
• Note 2 – this is a direct
communication between client
web app and auth server – it is
secure because client web app
passes client id and client
secret
client
web app
auth server
resource
server
18. 18
Authorization Code Flow – step 7
• Auth server responds with
“access token”
client
web app
auth server
resource
server
19. 19
Authorization Code Flow – step 8
• Client web app accesses the
resource server with access
token
client
web app
auth server
resource
server
20. 20
Authorization Code Flow – step 9
• Resource server verifies the
token with the auth-server
• Note – resource server has to
be configured with “user-info-
uri” in its application.yml
• Auth server sends back user
info back after verification
• If OpenID Connect is used
along with OAuth2, the
resource server should be able
to verify the validity of the
token, which contains JWT
(JSON Web Token)
client
web app
auth server
resource
server
21. 21
Authorization Code Flow – step 10
• Resource server responds back
with protected resource
• Client web app presents the
resource to the user
client
web app
auth server
resource
server
