Our current APIs and password protected websites currently use access tokens to retrieve information such as storage URLs and GA tracking keys. This works really well for our password protected websites and APIs where we utilize Authorization code flow with PKCE and client credentials flow.

However, in the case of our non-password protected websites(public), which also require access tokens to get the correct information from our APIs, we are unsure which OAuth flow to use.

Since the website(SPA) would authenticate as an application, rather than a user, it would feel natural to employ the client credentials flow here as well. However, since the site is purely front-end, it wouldn't feel right to simply expose the client id and client secret in the browser. We are aware that the access token would have to be easy to get(since it would have to be done in the browser), and thus wouldn't be "safe", but we are planning to heavily limit the access(specific read operations) which would be granted by such a token.

Any tips or recommendations going forward would be appreciated.

CodePudding user response：

If the web page is public then any data shown is public, so you should not care if a hacker accesses the information. Personally I would use anonymous API routes for public data, that do not require credentials, from either secured or unsecured clients.

If at an API level you want to require tokens, the SPA could call a utility API that implements the client credentials flow, in order to keep secrets out of the browser. This could return an access token or cookie to the browser that is then used by the SPA to call APIs. But any hacker could then use HTTP tools to grab the token or cookie, then play it against APIs directly, so there is zero security here.

OAuth scopes are likely to be essential for protecting the data correctly. If your public info is a list of products then unsecured clients might access it with the first scope. and secured clients with the second. APIs then need to ensure that the first scope can never be used to access secured resources:

• scope=public
• scope=products_read

To prevent unexpected behaviour you need to design an end-to-end solution, and think through the angles. This must ensure that introducing low privilege tokens (which have zero security) does not introduce its own vulnerabilities.