4. Problem Space
…. Money Manager follows the highest standards to keep your
information safe and secure. Read more about our security
practices.
Everyday Money Manager downloads data from your online
accounts. All you need to do is, share your online banking
user name and password. You need to add your online
banking user name & password only once. Your login
credentials are encrypted and we use the same encryption
technology (128-bit SSL) used by the world's top financial
institutions to ensure security of your data.
5. Before OAuth
• If a third party client app(s) wanted access to your
account/Resource, you’d give them your password.
Resource Server
(Service)
App 1
App n
App 2
Access User’s Resource using
Credentials
User / Resource Owner
Shares credentials with
Client app(s)
Credentials Credentials
Client App(s)
6. Sharing Credentials
Risks
• Apps store the user’s password (clear text passwords)
• Servers are required to support password authentication
• Overly-broad access granted
• Users can’t revoke access to an app except by changing their
password
• Compromise of third party app can compromise all of the data
including password
7. OAuth 2.0
• OAuth 2.0 addresses these issues by introducing an
authorization layer and separating the role of the client/third
party app from that of the resource owner.
• OAuth 2.0 authorization framework provides a method for
users to grant third-party limited access to their resources
without sharing their passwords.
• Uses concept of Access Token issued by Oauth2 server to
access resources hosted by Resource Server.
16. OAuth 2.0 Protocol flow
1
4 Access Token (AT)
returned
Authorization
Server
(Std. OAuth2
Server)
3
Resource
Server
(Service)
App 1
App 2
Authorization
Grant
Client App(s)
2
Authorization
Request
App n
Authorization Grant
5
6
AuthN via Access
Token (AT)
Response
Resource Owner
(User)
Access Token request
via Std. Oauth2 flows
17. OAuth 2.0 Roles
• Resource Server : The server hosting the protected resource
• Resource Owner : An entity capable of granting access to a
protected resource. User of the application.
• Client : An application making protected resource requests on
behalf of the resource owner. It can be a server-based, mobile
(native) or a desktop application.
• Authorization Server : The server issuing access token to the
clients after successfully authenticating the resource owner
and obtaining authorization.
18. End to End flow
The client requests authorization from the resource owner.
The client receives an authorization grant, which is a
credential representing the resource owner's authorization.
The client requests an access token by authenticating with
the authorization server and presenting the authorization
grant.
The authorization server authenticates the client and validates
the authorization grant, and if valid, issues an access token.
The client requests the protected resource from the resource
server and authenticates by presenting the access token.
The resource server validates the access token, and if valid,
serves the request.
19. OAuth 2.0
• Resource Owner’s credentials are not used to access
resources
• Credentials helps get an Access token to access Resources.
• Access token specifies scope, lifetime and other attributes
• The scope of the access request expressed as a list of space-
delimited strings e.g. read, write
• User can revoke access to specific client app(s) selectively.
20. • Access Token : Access tokens are credentials presented by
the client to the resource server to access protected resources.
It's normally a string consisting of a specific scope, lifetime and
other access attributes and it may self contain the authorization
information in a verifiable manner.
• Refresh Token : Although not mandated by the spec, access
tokens ideally have an expiration time which can last anywhere
from a few minutes to several hours. Once an access token is
expired, the client can request the authorization server to issue
a new access token using the refresh token issued by the
authorization server
21. Let’s look at them in detail
Authorization grant
Access token Request
Access token Response
Access token
22. Authorization grant
is an abstract term used to describe intermediate credentials
that represent the resource owner/user authorization.
Used by the client to obtain an access token from OAuth Server
Several authorization grant types are defined to support a wide
range of client types and user experiences
2 Access Token (AT)
returned
Refresh Token (RT)
Optional
Authorization
Server
(Std. OAuth2
Server)
1
App 1
App 2
Client App(s)
App n
Authorization Grant
Access Token request via
Std. Oauth2 flows
23. Authorization grant types
Authorization Code grant - web server apps
Implicit grant - Browser based, Mobile apps
Resource Owner Password Credentials grant – User
name/Password access
Client Credentials grant – application access
Extension grants – SAML/JWT token
Different client requires different flows
24. Authorization code (3-legged) flow
Authorization Code Flow: this flow includes sending the client user
via redirect to the provider’s login and authorization page, then will
redirect back to your web application and pass a authorization code in
the URL parameters.
You can then exchange this for an access token which you need to
pass on in your HTTP Request Headers to obtain access to the user’s
data.
With the access token, you also get a refresh token and information
about the expiry of the access token. You can exchange a refresh
token that you saved in your database at a later point against a new
access token for long-lived access.
30. User visits the authorization page
https://facebook.com/dialog/oauth?
response_type=code&client_id=28653682475872&redirect_uri=everydaycity.com&scope=email
31. https://example.com/auth?code=eyJhbGciOi[....... omitted for brevity]mljZUluc3RhbmNlMS5BTEwiLC
Authorization code grant – Web Server
apps
On success, user is redirected back to your site with auth code
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=eyJhbGciOi[....... omitted for brevity]mljZU
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
Client app sends Access Token Request to OAuth server
Here code is the authz code received from OAuth server.
grant_type must be authorization_code
32. HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Content-Type: application/json
{
"expires_in":604800,
"token_type":"Bearer","
“refresh_token":“ghtyhjh [...omitted for brevity...]FI“ ,
"access_token":"eyJhbG[...omitted for brevity...]FI“ }
Authorization server responds with Access Token in Response
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store Pragma: no-cache
{ "error":"invalid_request" }
In case of error Authz server responds with an Error Response
33. Client Credentials (2-legged) flow
• Flow consists of single request and response
• Client is also Resource owner i.e. acting on behalf of itself.
• The server will respond with a Access token, but there will
be no refresh_token issued typically.
• The client can use the returned access_token and simply
needs to authenticate again once the access_token has
expired.
35. Client Credentials (2-legged) flows
Client Credentials grant - client credentials in Basic Auth
header
Client Credentials JWT - client credentials will be send in the
form of JWT assertion
Client Credentials Basic Auth Header+ User Credentials JWT
Client Credentials JWT+ User Credentials JWT
37. Oracle OAuth 2.0 Server
Oracle Access Manager OAuth 2.0 Service provides a fully standards
compliant OAuth 2.0 authorization Server.
Support for both 3-legged and 2-legged OAuth flows
Client and service need to register with OAuth2 server.
Trust relationship should exist between client and OAuth server by
importing /exporting Client and OAuth certificates.
Oracle OAuth2.0 service should be enabled and configured to support
OAuth2.0 flows.
38. OWSM OAuth 2.0 Support
• Uses IDM OAuth2 Server as the authorization server for the OAuth2.0
protocol interactions
• Support various WS deployments –
a) Mixed cloud and on-premise deployments
b) Pure on-premise deployments
c) WSs interaction within and across Security domains.
• Support for both SOAP and REST WS
• Backward compatible with JWT Support in PS6MLR
39. Architecture Flows
WS Client App accessing a WS Provider App (SOAP or
REST)
OWSM transparently
performs 1/2/3 (Policy Driven)
WS Client App
Resource Server
(WS Provider App
SOAP/REST)
AuthN, get OAuth2 JWT Access Token (AT) via Std OAuth2 flows
WS Client App accesses resource using the OAuth2 JWT AT token
1
2
OAM
OAuht2
Server*
OWSM
Server
Agent
Security Domain
Opaque JWT Access Token (AT) and
Refresh Token (optional) returned
OWSM
Client Agent
Authorization
Server
(Std OAuth2
Server)
3
Authz
Grant
Access
Token
Access
Token
Refresh
Token
40. OWSM OAuth 2.0 Support
• OWSM provides OAuth2 support by means of OWSM Security
policies. In order to use OWSM OAuth2 support attach following
policies at service and client -
Service Side policies – Any jwt token policy
http_jwt_token_service_policy
http_jwt_token_over_ssl_service_policy
multi_token_rest_service_policy
multi_token_over_ssl_rest_service_policy
Client side policies
http_oauth2_token_client_policy
http_oauth2_token_over_ssl_client_policy
and
oauth2_config_client_policy – must be attached along with any of above policies
at client side.
41. OWSM OAuth 2.0 Support
OWSM Client side policy enforcement –
Integrates with OAuth2 server to obtain access token.
Parses the Access token response from Oauth2 server and send it to
the service in “Authorization:Bearer” header.
Refresh the expired Access Token
43. Configuration overrides
http_oauth2_token_client_policy
Config Property Description
oauth2.client.csf.key This is the only required config override with default value of
basic.client.credentials. This CSF key will be used to obtain the client
username and password.
federated.client.token This is an optional config override to set to false by default. When its
set to true, JWT token will be generated for the client using
“oauth2.client.csf.key” and “keystore.sig.csf.key”.
scope This is an optional config override. If present, the “scope” parameter
will be included in the OAuth2 token request with this value (as is).
issuer.name This is the issuer name that will be used for the locally generated
JWT token (iss:claim). By default it is www.oracle.com
user.attributes This is an optional config override. If present, the user.attributes will
be inserted as claims in JWT token
user.roles.include If this config override is set to true, the user.roles from the Subject
will be included in the JWT token as claims.
propagate.identity.context If this config override is set to true, the identity context information
will be propagated as claims in the JWT token.
keystore.sig.csf.key This config override will be used to fetch the tenant key/cert from
OWSM keystore for signing the JWT token.
user.tenant.name If this config override is present, the value of this config override will
be inserted in “user.tenant.name” claim.
44. OWSM OAuth 2.0 Support
OWSM Service side policy enforcement –
Extract the Access token from request and validates it.
If no Access token found issues a 401 challenge
WWW-Authenticate: Bearer realm=www.oracle.com
If token is expired throw a 401 Unauthorized error.
If token is not expired
Verifies if issuer is trusted, audience claims, sign algorithm
Verifies signature of JWT token, claims
Verifies if certificate of JWT (AT) token is trusted.
Assert Identity
