Hi Shane,
I have a question about the "On Token Expiry" section of that flow. Specifically, how should the App Server determine that the client should be able to trigger the Refresh Token flow and how the App Server shuold link the Refresh Token to the specific client?
As I understand it, at that point in the flow, the client has the following items:
1. The expired Access Token
2. The Authorization Code. Some providers (eg. Azure AD) only allow this code to be used one time, so it is no longer directly useful for retrieving an Access Token from the Oauth Services and the Refresh Token should be used instead.
3. The PKCE. It's unclear from that diagram, but I believe the PKCE can be generated either on the client or an App Server endpoint, but allowing the client to keep track of it is a good idea. The only reason we would generate the PKCE on an App Server is because different browsers might have different crypto libraries with varying degrees of maturity.
4. The client does not have the refresh token.
a. How should the Expired Access Token, the Authorization Code, and the PKCE be used to tell the App Server to trigger the refresh flow?
b. Should the App Server maintain state or a database that links the Access Token + Auth code + PKCE to the Refresh Token, so a requester needs all three to trigger the refresh token flow so that an attacker would need to compromise the (now expired) Access Token, the Auth Code, and the PKCE to trigger the refresh token and obtain a new Access Token?
c. Should the App Server forward the refreshToken to the client and statelessly accept the refreshToken in the request and simply serve as a proxy to inject the client_secret into the /token request and/or provide some custom logic (eg. API_KEY, IP whitelist, throttling, etc)?
Should the SPA client request a new authorization code and request a new Access Token + Refresh Token (on the App Server) every time that the user visits the SPA? Would there be any harm in doing so?
------------------------------
Aidan Hoolachan
------------------------------
Original Message:
Sent: Fri June 28, 2019 02:18 AM
From: Shane Weeden
Subject: Best Practice OAuth 2.0 Pattern for Single Page App
The recommended approach is to deploy azn code flow with PKCE and a confidential client, with the client credentials and the real connections to the token endpoint managed by an app-server component of your overall SPA solution. You would use standard TLS+browser cookie for security between the SPA and the backend token management component that you write yourself (using whatever communications APIs you want).
This approach is the thinking of the working group that's coming up with deployment best practices security recommendations for OAuth 2.0. The main reason behind the recommendation is that there are far less things that you are likely to get wrong or accidentally miss than when doing things with the implicit flow. Getting the implicit flow wrong (which is easy to do according to their thinking) would leave exploitable security issues in your solution.
I never heard anybody actually say that implicit *cannot* be deployed securely, just that it is quite difficult to get everything right.
------------------------------
Shane Weeden
IBM
Original Message:
Sent: Thu June 27, 2019 09:13 PM
From: Sylvain Gilbert
Subject: Best Practice OAuth 2.0 Pattern for Single Page App
Hello Jon, and all !
I could not attend this year's ISAM MasterClass in Orlando, but I managed to get a hold on the presentation material, which keeps improving year after year.
In the "SAM-General-OAuth and API Economy" presentation material, the sequence diagram "Best Practice OAuth 2.0 Pattern for Single Page App" is presented to illustrate one integration pattern for SPA applications & OAuth. It is very interesting, but It is not commented so I can only try guessing the rational for each decision made.
I was wondering if you had any additional material visiting more in depth this pattern, or if not, if you could briefly share with us the highlights about why this pattern is the "best", in what context, its down side, etc.
Thank you
Sylvain