Let’s consider a single page client side application, developed using HTML and Javascript.

In this case, even if the implicit or authentication code flow is being used to request Access Tokes, still the clientID and Secret would still be found in some Javascript, which might be making the token requests. Plus, passing the Access Token in the request header (or query parameter) are still visible in the network trace. Moreover the Access Token needs to be stored locally in a browser.

  • How secure it is to use OAuth2 for web based applications??
  • How the user information can be protected, if the client (browser) is compromised.


  • 2
    Welcome. :) This is a bit of a loaded question. OAuth2 isn't the problem, it's the implementation. In this case, you are absolutely right - client ID and secret would be exposed in JavaScript if you expect to get data back from the provider. oauth.com/oauth2-servers/single-page-apps has more information. Can you clarify the question further? However, OAuth2 is quite appropriate for applications with a server component.
    – h4ckNinja
    Jan 17, 2019 at 2:06

3 Answers 3


there is recent guidance on how to handle this client-side applications with regards to OAuth2 protocol: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-11

TL;DR: the recommendation is to go with OAuth2 Authorization Code with PKCE on top. I can only recommend this very good article for the details of implementation: https://auth0.com/blog/oauth2-implicit-grant-and-spa/


Usually OAuth is used by a user to give access to resource to a third party, which is the client in the OAuth framework. So in the implicit flow the user might see the access token, however they already had access to begin with so that is not a problem.

The more secure method though is to not use the implicit flow. This then gives you an access code that you have to combine with your client credentials to obtain a access token. You don't do this in the user's browser using javascript. Instead you have your server side software capture the access code and do a back channel call to the authorization server to get the access token. Now the user or any one else snooping around never actually has enough information to get your access.

So the steps are like this:

  1. Redirect user to authorization server
  2. User authenticates and provides consent
  3. User is redirected to Client with access code (or error code)
  4. Client webserver captures the access code
  5. Client backend exchanges the access code for an access token through a direct back channel call to the authorization server (notice the user's browser is not involved here)
  6. Client can now use the access token, and possible refresh token, to access the resources the users has provides access to.

In the steps above the user's part is done after step 3. So you don't want to be depending on the user's browser to finish running your javascript. Not only would this cause security issues as you described, but it would also make execution of steps 4, 5 and 6 uncertain and probably degrade your user experience if you require them to stick around of a long processing task. Instead you can do all that on the backend without the user needing to be involved.

If you implement OAuth correctly it can be a very secure way authorisation. But that is a big if.


If everything is in JavaScript then you can't trust the browser, so it's better to just use a public endpoint (no client_secret). It's really no different than exchanging a username/password for a cookie.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .