As thats how implicit works, the token is “protected” from view as it’s “expected” under implict that no server exists.
Generally speaking:
- implict is when you don’t have a backend server/service to handle tokens so when using implict, generally your server doen’t/shouldn’t touch the tokens
- if you hae a backend server/service and you want the backend to touch/see the token then you use code flow instead.
Broadly speaking you have used the wrong flow. Hence your need to
So really you should be using code flow for the described use case (or maybe DCF not sure as you were thin on the use case describing)
So for example:
- my chatbot uses code flow (as it has a server/backend and I need refreshable tokens
- my github exampels uses implicit flow as there is no backend server logic (and there can’t be since it’s all front end javascript doing the calls)
Additionally:
if the token was ?queryParametered then it would be logged into server access logs.
Under code flow only the exchange code is leaked into server access logs and that only has a 10/15 minute life time and is short use.
Under implict the fragment can never be leaked into server access logs. and so the access token isn’t leaked into server access logs
Finally: it’s how it’s supposed to be done accoridng to the RFC: RFC 6749 - The OAuth 2.0 Authorization Framework and RFC 6749 - The OAuth 2.0 Authorization Framework
If the resource owner grants the access request, the authorization
server issues an access token and delivers it to the client by adding
the following parameters to the fragment component of the redirection
URI using the “application/x-www-form-urlencoded” format, per
Not the lack of a RFC SHOULD this is how it MUST be done