5G/ Making OAuth 2 Secure

From IIW

OAuth High Assurance FAPI


Wednesday 4G

Convener: Nat Sakimura

Notes-taker(s): Michael Schwartz


Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:


OAuth 2.0 is not optimized for high assurance use cases.

Authorization request and response is not protected.

-Susceptible to insertion attacks: eg code insertion, state insertion


Token and client credentials are 'bearer'

-They are susceptible to a variety of token capture attacks, including code phishing


There is no explicit issuer for the tokens (incl. code)


Redirection URI at the client is a proxy for the issuer identifier

This means the redirect uri needs to be unique for each AS

In Finc'l API working group:

  - Use request object / request URI  / signature required

  - Use hybrid flow with id_Token in the front channel as a detached signature

  - include s_hash in the id_token - state hash


Bind tokens to TLS client certificates or use token binding.


Mutual TLS profiles for OAuth Clients - draft-cambell-oauth-mtls


Perhaps client private key authentication at the token endpoint is almost as good mutual TLS, althouhh it lacks some of the replay protections. But due to specification of mutual client authentication by UK banking regulations, and the greater availability of infrastructure to handle this, mutual TLS was preferred.


The following is an example of a JWT payload

 {

"iss": "https://idp.example.com",

"aud": "https://rp.exmaple.com",

"sub": "foo@bar.com",

"exp": "1493726400",

"nbf": "1493722800",

"cnf": {

  "x5t#S256": "bsdfsdaflkasjdflksadjfkldsklfbnsadlfnsdklflkasdfasdff-dg2",

}

 }


The client would have to register the auth_subj_dn and the auth_issuer_dn at the AS. From a deployment perspective, it adds some complexity. Certain deployment models could interfere with this mechanism (like use of Amazon ELB service.)


The OpenID Connect federation spec perhaps could be used to add extra security over TLS. How do fintech services get authorized to register for client credentials at banks? How do banks publish their stable signing keys?

What format software statements would use to register is still up for discussion.


OpenID Connect Financial API


http://openid.net/wg/fapi

Currently working on part 1 and part 2


Part 1: Requirements for Read

Section 5.2.2 Authorization Server

5.2.3 Client requirements


Part 1: Requirements for Write (more risk)


FAPI proposes a new request object endpoint in the AS--the RP would POST the request object to the API which would return a JSON with the request object URI. The client could then use the request_uri in the authorization request.


Brian Cambell from Ping expressed some concern about requesting the request object from a URI, which has low adoption in practice right now anyway. He said it's hard to get right.