Nathan Blair
I think what the PKCE solution allows could be done with just enforcing a state nonce as well, and allows for one less round trip. Encode the code challenge, embed it in the state (or even just add the code verifier/challenge to the implicit flow as parameters), have the server send back the access token and the state and/or code challenge. Send the access token in addition to the decrypted state nonce and/or code verifier in all API requests. Server side, it only means checking one additional entity. Effectively, the access token is your proof authentication, the additional parameter becomes your proof of authorization.
I could probably have explained that better but it’s still early lol. I agree that there’s a vulnerability issue with the implicit flow though. But at least (if done correctly) access tokens have a short lived expiration time. There’s no way to renew them unless an extension was able to authenticate on your behalf, and at that point, I don’t think it’s an OAuth issue as a browser/HTTP(S) issue.
It may be time we re-architect-ed our approach to secure access of APIs. Insomuch that we move forward with the notion that there’s no such thing as secure storage, short of, at best, living in memory.
There’s this notion of: the user wants to experience the convenience of being logged in even after they navigate away from the page or close a tab/window. But maybe there’s a radically different approach where we end up with a more secure solution. I don’t know what that is, but I think the person that figures it out is going to make the world a much better place 