Using Oauth2 there are several grant types - however I am truly confused in what grant type to use as all seem to have some major security concerns over a manual login.
Our application consist currently of two servers:
Now I studied some examples of oauth2, and while the examples show how things can be done they all seem to unsafe, completely oblivious for xss or other attacks. On top of that the login process became quite a bit of a weird user experience flow.
The best solution seems to be: "Authorization Code Flow with Proof Key for Code Exchange (PKCE)". However the documentation on pkce doesn't seem to specify what happens when the access token is generated and how it should be handled by the client (SPA application).
The examples I have seen so far are basically three steps:
Step 3 is what I am confused about. Isn't this really vulnerable to xss attacks or malicious extensions in the user's browser. Something that cookies were made to prevent? And in being so, isn't this a step back from the invention of htmlonly cookie etc?
Secondly, the third step seems very poorly documented, in the implicit flow there is a "redirect" parameter part of the oauth2 protocol, in the "authorization with Proof Key for Code Exchange (pkce)" this isn't really described anywhere?
So am I missing step to bring the access token "back" to the SPA so it can be shared with the resource server?
You should run a code flow, using a grant_type of authorization_code
. This never returns an access token in browser responses. Instead it returns an authorization code. which is swapped for tokens. Also use PKCE to prove that the party beginning login is the party ending it.
Also be aware of the architecture patterns from OAuth for browser based apps. In terms of best security, a backend for frontend (BFF) is often used, that issues secure cookies on behalf of the SPA, with fewer XSS risks. This also enables you to attach a backend client secret when getting tokens.