This document provides an overview of microservice security using Spring Security 5.1, OAuth 2.0, and OpenID Connect. It defines OAuth 2.0 and its authorization framework, describing how applications can be authorized to access user data. It outlines the authorization code grant flow and other grant types, including how applications register and use client IDs and secrets. JSON Web Tokens are discussed as an access token format. OpenID Connect is described as extending OAuth 2.0 to provide authentication via ID tokens. Key components like access tokens, refresh tokens, and the client credentials flow are also summarized.
6. Definition
OAuth 2.0 Authorization Framework :
Is a framework for allowing users to authorize applications to access their data on
there behalf.
Authorized applications get an access token that they can use to call a service.
Does not tell the authorized application anything about the identity of the user
Does not specify a token format. Expects other frameworks to extend it.
37. Application Registration
To participate in OAuth, your application has to first register with the service
provider (Google , Facebook, and so on) against which you plan to authenticate
by providing the application name, application URL, and callback URL.
The callback URI is where the service will redirect the user after they authorize
(or deny) your application, and therefore the part of your application that will
handle authorization codes or access tokens.
Successful registration of your application with the service provider gives you two
values unique to your application: client application_id and client_secret. client_id
can be exposed publicly but client_secret is kept hidden (private). Both these
values are needed whenever you access the service provider.
38. Client ID and Client Secret
Successful registration of your application with the service provider gives you two
values unique to your application: client application_id and client_secret.
client_id can be exposed publicly but client_secret is kept hidden (private). Both
these values are needed whenever you access the service provider.
The following diagram shows the interactions between these roles:
39. The steps in the preceding diagram detailed here:
1. The client application requests the resource owner to give them authorization to
access the secured resources
2. If the resource owner authorizes this, the authorization grant is sent to the client
application
3. The client application asks for a token, using the grant provided by the resource
owner along with authentication credentials from the authorization server
4. If the credentials and grant from the client application are valid, the
authorization server issues an Access Token to the client application.
5. The client application accesses the protected resources on the resource server
using the Access Token provided 6. If the Access Token sent by the client
application is valid, the resource server gives access to the secured resources
40. Authorization Grant Types
A grant type defines how a client can obtain an authorization grant from a
resource owner to access a resource on their behalf.In the Abstract Protocol Flow
above, the first four steps cover obtaining an authorization grant and access
token. The authorization grant type depends on the method used by the
application to request authorization, and the grant types supported by the API.
OAuth 2 defines four grant types, each of which is useful in different cases:
41. Authorization Grant Types
● Authorization Code: used with server-side Applications
● Implicit: used with Mobile Apps or Web Applications (applications that run on
the user's device)
● Resource Owner Password Credentials: used with trusted Applications,
such as those owned by the service itself
● Client Credentials: used with Applications API access
42. Authorization code flow
This a is very commonly used grant type and works on redirection at the server. It
is highly suitable for server-side applications where the source code is hosted on
the server and nothing is available on the client. The following diagram explains
the authorization code grant type flow:
43. Grant Type: Authorization Code
The authorization code grant type is the most commonly used because it is
optimized for server-side applications, where source code is not publicly exposed,
and Client Secret confidentiality can be maintained. This is a redirection-based
flow, which means that the application must be capable of interacting with the
user-agent (i.e. the user's web browser) and receiving API authorization codes
that are routed through the user-agent.
44. Grant Type: Authorization Code
1. The resource owner of the secured resource is presented with a screen in the
browser to authorize the request. Here is a sample authorization link:
https://<DOMAIN>/oauth/authorize?response_type=code&client_id=<CLIENT_ID>
&redirect_uri=<CALLBACK_URL>&scope=<SCOPE>
45. Grant Type: Authorization Code
These are the important query parameters in the previous link:
client_id: The client application ID that we got while registering the application
with the service provider.
redirect_uri: After successful authorization, the server redirects to this URL
supplied.
response_type: A very important parameter the client uses to ask the server for
the authorization code
scope: Specifies the level of access that it requires
46. Grant Type: Authorization Code
2. If the resource owner (user) allows this, they click on the authorize link, which is
sent to the authorization server.
3. If the authorization request sent to the authorization server is validated and
found to be successful, the client receives the authorization code grant from the
authorization server appended as a query parameter in the callback URL
(<CALLBACK_URL>?code=<AUTHORIZATION_CODE>) specified in Step 1.
4. Using the authorization grant, the client application requests an Access Token
from the authorization server
https://<DOMAIN>/oauth/token?client_id=<CLIENT_ID>&client_secret=<CLIENT_
SECRET>&grant_type=authorization_code&code=<AUTHORIZATION_CODE>&r
edirect_uri=CALLBACK_URL).
47. Grant Type: Authorization Code
In this URL, the client application's client_secret also has to be passed, along
with the grant_type parameter, which states that the code passed is the
authorization code.
5. The authorization server validates the credentials and authorization grant and
sends the Access Token to the client application, preferably in the form of JSON.
6. The client application calls the protected resource on the resource server using
the Access Token received in Step 5. 7. If the Access Token supplied in Step 5 is
valid, the resource server gives access to the secured resource.
48. Grant Type - Client Credentials
The client application sends credentials (the client's service account), along with
client_ID and client_secret, to the authorization server. If the supplied values are
valid, the authorization server sends the Access Token, which can be used to get
access to the secured resources.
49. Grant Type - Client Credentials
Request Parameters
grant_type (required)
The grant_type parameter must be set to client_credentials.
scope (optional)
Your service can support different scopes for the client credentials grant. In
practice, not many services actually support this.
Client Authentication (required)
The client needs to authenticate themselves for this request. Typically the service
will allow either additional request parameters client_id and client_secret, or
accept the client ID and secret in the HTTP Basic auth header.
50. Access Token and Refresh Token
The Access Token can be used by the client application to retrieve information
from the resource server for a stipulated time for which the token is deemed valid.
After this, the server will reject the request with the appropriate HTTP response
error code. Along with the Access Token, OAuth allows the authorization server to
also send another token, the Refresh Token. When the Access Token expires, the
client application can use this second token to request the authorization server to
provide a new Access Token.
51. JSON Web Token (JWT)
"JSON Web Tokens are an open, industry standard RFC 7519 method for
representing claims securely between two parties."
Each request sends the cookie (session ID) in the form of an HTTP header, which
gets validated by the server, and a state (a user session) is associated with each
request. In modern applications a server-side session ID is replaced with the JWT.
The following diagram shows the workings of the JWT:
54. JWT
The web server, in this case, doesn't create a user session and the user session
management capability needed for a stateful application is offloaded to other
mechanisms. In the world of the Spring Framework, the Spring Session module
can be employed to externalize the session from the web server to a central
persistence store (Redis, Couchbase, and so on). Every request containing a valid
token (JWT) is validated against this external store of authenticity and validity.
After successful authentication, applications can generate a valid token and send
it as a response to the client. The client can then store this token in any client
storage mechanism it uses (sessionStorage, localStorage, cookies, and so on, in
a browser). Using Spring Security, we can validate this token to ascertain the
authenticity and validity of the user and then do whatever is required
55. Structure of a token
The structure of the JWT consists of a header, payload, and a signature. As
mentioned, rather than encryption, the data contained within the JWT is encoded
and then signed. Encoding does the job of transforming the data in a way that is
acceptable by a variety of parties and signing allows us to check for its authenticity
and, in fact, its origin:
Header This is a JSON object and takes the following format. It gives information
on how the signature should be computed.
{
"alg": "HS256",
"typ": "JWT"
}
56. PayLoad
The payload forms the actual data (also known as a claim) stored in the JWT.
According to your application's requirements, you can put any number of claims
into your JWT payload component. There are some predefined claims, such as iss
(issuer), sub (subject), exp (expiration time), iat (issued at), and so on, that can be
used, but all of these are optional:
{
"sub": "1234567890",
"username": "Test User",
"iat": 1516239022
}
57. OpenID Connect
OpenID Connect implements authentication as an extension to the
OAuth 2.0 authorization process. Use of this extension is requested
by Clients by including the openid scope value in the Authorization
Request. An Authorization Request using these extensions is called
an Authentication Request.
Information about the authentication performed is returned in a
JSON Web Token (JWT) [JWT] called an ID Token (see Section
2.2). OAuth 2.0 Authentication Servers implementing OpenID
Connect are also referred to as OpenID Providers (OPs). OAuth 2.0
Clients using OpenID Connect are also referred to as Relying
Parties (RPs).
58. OpenID Connect - Id Token
ID Token-
With OpenID Connect authentication, there is an additional type of
OAuth token: an ID token. The ID token, or id_token, represents
the identity of the user being authenticated. This is a separate
token from the access token, which is used to retrieve the user’s
profile information or other user data requested during the same
authorization flow.The ID token is a JSON Web Token (JWT), which
is a digitally signed and/or encrypted representation of the user’s
identity asserted by the identity provider. Instead of using
cryptographic operations to validate the JSON Web Token, it can
be treated as an opaque string and passed to the Check ID
Endpoint for interpretation (see below). This flexibility keeps with
59. OpenID Connect - Id Token
ID Token-
With OpenID Connect authentication, there is an additional type of
OAuth token: an ID token. The ID token, or id_token, represents
the identity of the user being authenticated. This is a separate
token from the access token, which is used to retrieve the user’s
profile information or other user data requested during the same
authorization flow.The ID token is a JSON Web Token (JWT), which
is a digitally signed and/or encrypted representation of the user’s
identity asserted by the identity provider.
