Oauth2 and OWSM OAuth2 support

Gaurav Sharma29 September 2014

OAuth2.0 and OWSM OAuth2 Support

Agenda Why OAuth ? Introduction to OAuth 2.0 OAuth 2.0 flows Authorization grants Access token Refresh token OWSM OAuth2 Integration

Additional topics OAuth2 server configuration Securing application (SOA/REST/ADF) using

OWSM OAuth2 security policies

Problem Space

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.

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 OwnerShares credentials with Client app(s)

Credentials Credentials

Client App(s)

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

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.

Some current Implementations

Client App – using Twitter/ Facebook as Authorization / OAuth server

Limiting access to third parties



OAuth 1.0

• April 2010 • RFC 5849• Informational - Not a standard. • OAuth 1.0a – 2009• OAuth 1.0 is a protocol.

• Initial Players:Twitter, Ma.gnolia

OAuth 2.0

• Oct 2012• RFC 6749, 6750• IETF standards track RFC• OAuth 2.0 is a framework• Not backward compatible

• Initial Players:Yahoo!, Facebook, Salesforce, Microsoft, Twitter, Deutsche Telekom, Intuit, Mozilla and Google.

OAuth

OAuth 1.0a

• Flickr• LinkedIn• Netflix• Tumblr• Twitter• Yahoo• Yelp• MySpace

OAuth 2.0

• Facebook• FourSquare• GitHub• Google• Instagram• Microsoft• PayPal• Yammer• bitly

OAuth

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

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.

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.

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.

• 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

Let’s look at them in detail

Authorization grant Access token Request Access token Response Access token

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) returnedRefresh Token (RT)Optional


(Std. OAuth2 Server)

1

App 1

App 2

Client App(s)

App n

Authorization Grant

Access Token request via Std. Oauth2 flows

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

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.

https://facebook.com/dialog/oauth?response_type=code&client_id=YOUR_CLIENT_ID&redirect_uri=REDIRECT_URI&scope=email

Authorization code grant – Web Server apps – Facebook example

Create a login link sending the user to Authorization Server.










The redirect URI must be registered with the OAuth Server.




User visits the authorization page

https://facebook.com/dialog/oauth?response_type=code&client_id=28653682475872&redirect_uri=everydaycity.com&scope=email

https://example.com/auth?code=eyJhbGciOi[....... omitted for brevity]mljZUluc3RhbmNlMS5BTEwiLC

Authorization code grant – Web Server appsOn 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-urlencodedgrant_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 serverHere code is the authz code received from OAuth server.grant_type must be authorization_code

HTTP/1.1 200 OKCache-Control: no-cache, no-store, must-revalidatePragma: no-cacheContent-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

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.

HTTP/1.1 200 OKCache-Control: no-cache, no-store, must-revalidatePragma: no-cacheContent-Type: application/json

{ "expires_in":604800,"token_type":"Bearer",""oracle_tk_context":"client_assertion","oracle_client_assertion_type":"urn:ietf:params:oauth:client-assertion-type:jwt-bearer","access_token":"eyJhbG[...omitted for brevity...]FI“ }

POST /ms_oauth/oauth2/endpoints/oauthservice/tokens HTTP/1.1Content-Type: application/x-www-form-urlencoded;charset=UTF-8Authorization: Basic T1dTTUNsaWVudElkOndlbGNvbWUxHost: 127.0.0.1:2001Accept: text/html, image/gif, image/jpeg, */*; q=.2grant_type=client_credentials

Client Credentials grant – Basic AuthAccess Token Request -

Access Token Response

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

Access Token (decoded) – Client credentials

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.

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

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


(Std OAuth2 Server)

3

Authz Grant

Access Token

Access Token

Refresh Token

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_policyhttp_jwt_token_over_ssl_service_policymulti_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.

OWSM OAuth 2.0 SupportOWSM 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

Configuration overrides oauth2_config_client_policy

Config Property Descriptiontoken.uri This is a mandatory configuration override for

configuring the OAuth2 server token endpointe.g. http://host.us.oracle.com:port/ms_oauth/oauth2/endpoints/oauthservice/tokens

Configuration overrides http_oauth2_token_client_policy

Config Property Descriptionoauth2.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.

http://www.oracle.com/

OWSM OAuth 2.0 SupportOWSM 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

http://www.oracle.com/

Questions -

email: [email protected] blog: http://technotesgaurav.blogspot.in

http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-05

http://technotesgaurav.blogspot.in/

Documents

Oauth2 and OWSM OAuth2 support