5G/ Making OAuth 2 Secure
OAuth High Assurance FAPI
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
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
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.