How safe or unsafe is it to expose your Client ID on the front-end?
Client ID can be exposed in your front end or client side applications.
Client secret should not be exposed.
1 Like
TL;DR of why solely exposing your client ID is of no harm?
Because that’s the only thing my client is sending to the Twitch API, so can’t other users use that exact same path?
Unfortunately I cannot provide you with a TL;DR. But:
If you’re using the OIDC or the OAuth Implicit Code Flow, this is correct. You only need the client ID for that.
On the other hand, you need both, client ID and client secret for the OICD/OAuth Authorization Code Flow.
The difference between both flows is that with the second one, you only get a temporary authorization code sent back to your redirect URI instead of the final user access token. Because of this, you still have to make another request to the Twitch server where you send this temporary authorization code and receive (in exchange) the final user access token. Only with this request, you have to use the client secret.
Also, with the implicit flow, the final user access token is part of the anchor hashtag of the redirect URI, so only the client is able to see the final user access token, the server logs will not get it. On the other hand, with the authorization flow, the server is the only one seeing the final user access token, because it is solely responsible for exchanging the temporary authorization code for a user access token and noone else can do that because the client secret is required in this process.
So both flows are different in the way the final user access token is stored (either only by the server, or by the client).
So indeed, the implicit flow is solely client-sided and everyone reverse-engineering your client can use your client ID to clone this process.
So yes, others can go the exact same path when you’re using the implicit flow.
Sure, they can only send someone back to exactly your redirect URI, because the redirect URI cannot be changed (it is defined in your developer application settings).
But someone reverse-engineering your client can just intercept the redirect URI call and grab the token from there, so he is technically still able to “steal” the user access token using your client ID.
But this is exactly why the other authorization flow exists.
Also, user access tokens granted with the implicit flow do not live as long as the ones granted using the authorization flow and they also cannot be refreshed exactly because of the reason (implicit flow being less secure than authorization flow).
There might also be the question why the implicit flow exists in the first place, if it’s not that good.
Well, some applications just don’t have a server (desktop application without backend e.g.), so sometimes this flow is required because you have no other way of doing it.
ClientID’s are public in the URL for Auth
ClientID’s for authorisation include a redirectURI which can only go to one place after authorisation is granted/denied.
That’s correct. Client ID is public information. The security around use of the Client ID is based around the use of the redirect URI, so just make sure your Redirect URI is to a service that you own.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.