KtorZ
commented
6 years ago Well, you only have to use the client_secret as part of the Client Credentials flow or, if you enable Basic authentication on your request. I don't see any scenarios where you would want to do that on a client-side application for the reasons you've just mentioned.
Those elements are there for completeness as they are part of the OAuth 2.0 protocol. A warning about their usage may actually be useful. In practice, you would want to use the Implicit, Authorization Code or Resource Owner Password Credentials flow. In the case of the Authorization Code, the second call to retrieve the token from the Authorization Server is usually done server-side (such that it can be authenticated with a secret without leaking on the frontend).
By the way, most OAuth AS will expect that you provide registration_uris at the moment of creating new clients and will verify that the user-agent is only redirected to one of this approved uris. This provides an extra security layer you may want to leverage (for instance, by using your server as a gateway to add your client_secret to a request).
Also, remember that OAuth 2.0 isn't an authentication protocol. Your server will still have to provide a mechanism to verify users identities and maintain their session open if any. In the case of a SPA directly consuming an API, OAuth 2.0 has become quite widely accepted as a way to authorize applications for a fix period of time but you would want to authenticate your user for any sensitive operations (like updating their own information or performing a non-reversible action).
Also, in the case you would store refresh_token client-side, make sure they are stored in a safe-place without risk of being eavesdropped by a malicious actor. You usually don't need refresh tokens as users maintain their sessions active on the AS and don't remove your authorization. So, as an application, you can pretty much perform the whole flow a second time if needed without having the user to consent again (since he already granted your application access to).
If you are interested in more details / information, please have a look at the following links:
https://oauth.net/articles/authentication/ https://tools.ietf.org/html/rfc6749#section-10
Hello, I'd like to know if it is actually recommended to run the OAuth Web Flow on the client side, like this package allows? Doesn't the Authorization Code Flow obligates the client secret to be on the client side, thus much more easily found out?
Probably it even has to be hard-coded into the app, since Env Vars cannot be used, right?
I was thinking about using this package, but I fail to see how this can be feasible from a security standpoint. I'd like some help in understanding this!