![]() Please note that the client id is not considered secret information. This also means that your application cannot authenticate against the authorization server which might be acceptable for a hobby project, but not in an enterprise or high security context. In this case, you will not get a client secret. If your project is a pure single page application and does not have a backend in the sense that you run your own server that can protect secrets, then, while registering your application, you must select that you want the OAuth Authorization code grant, but that you are running a public client. You should use the OAuth Authorization code grant. When an end user is involved, client credentials grant is definitely the wrong OAuth grant choice. Putting the client secret in the frontend immediately compromises your entire application. When using the client credentials grant, the third party is expected to be a confidential client (makes sense because we are talking about machine to machine communication). The OAuth client credentials grant is designed for machine to machine communication, i.e. A confidential client is a third party application that can protect secrets mobile apps that do not use dynamic client registration or SPAs).Ī public client is a third party application that cannot protect secrets. You are using an OAuth / OIDC grant that is not suitable for public clients (e.g. I'm sure I'm not being clear about the specifics. However if you setup CORS on to accept requests from it suddenly starts working. This would generally work on React without setting up CORS on express. ![]() Lets say you try to access that works from a React app running on, but doesn't work. If you're developing locally they generally just allow all requests from localhost.ĬORS, if a website tries to access an endpoint on a different origin it will be prevented because React(or some other framework/browser) is trying to prevent a cross scripting attack. So it connects a specific JWT to a specific origin. Services like the Spotify API cannot whitelist an address for CORS to every client request, they have to protect their service in a different way. For the sake of argument the difference is treated the same as if the second URL was the server doesn't care why they're different for API authentication calls, it just cares that they're different. In the case of authorization these are treated as separate URLS. One is trying to access from port 443(https) and one is trying to access from port 80(http). If /apitries to access the same endpoint with the same token it would be rejected. It is a similar but different security thing.įor example: I create a security token and code to make sure that the client using the token is. You can whitelist various origins as part of CORS, but other servers you can say that this credential(JWT) will only ever work with this origin(URL, IP address whatever). Your backend you can lock down further and really only expose an api key and you can lock it down to only accept requests from your frontend origin. That request to your backend would then make its own request to Spotify api using the correct data. The 'correct' way to approach it would be have your frontend make a request to your backend to do something(get playlist info or something). Unless someone is requesting from all requests would be rejected. The reason being is that the only valid requests come from the specified origin. If you expose your key, and your frontend is behind https(with a valid cert) in theory it shouldn't be a big deal. ![]() I think the Spotify API allows you to set a valid origin(i.e. ![]() But the core of this is: anything on the client/frontend should be treated as visible to the user. Some solutions like Nextjs can have api routes on the edge to circumvent some of this. If you want this hidden those types of interactions and secrets should exist on the backend. TLDR: If it's part of the client code it is available for anyone to read. Why does it appear in the frontend demo but not in the main fullstack project? Is it because it holds backend credentials? What if I put the cliend secret and id there, would they show although the are needed for a frontend part of the website? How can I hide them? Something I don't understand is that the demo I made where I can see the client id and secret in the devtools is a frontend demo that I want to incorporate into a fullstack project which already has a different config file that contains credentials but that config file cannot be found in the devtools. I thought if I put them in a config.js file and imported them then maybe they wouldn't appear but the config.js file appears. I've been able to fetch the data I want and display it but the problem is that the client id and secret appear in the sources section of the devtools. To do so I provided a client id and secret and received a bearer token. I connected to the Spotify API using their client credentials flow. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |