I’m a bit confused about how implicit grant flow is supposed to work:
you’re supposed to be running a web server locally so that there’s somewhere for the redirect_uri to go, because it’s meant for apps without a server component.
You send the user to the /oauth2/authorize endpoint with all the query parameters filled, then you wait for the user’s browser to send them to that local web server, but it’s passed in the fragment rather than the query portion, which is omitted from the actual http request.
So your local web server is then supposed to serve a page with some dummy javascript which extracts the fragment and immediately re-calls your web server with it as a query parameter so that your app can get the access token?
What’s the reason that a fragment is used requiring these extra steps instead of just a query parameter like the error is? You can easily tell that it’s an error from the presence or absence of the error parameters.
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
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
Thanks!
If I could make a documentation suggestion for other developers who are as thick as I am
I went with IGF because it seemed to have the best UX and “if your app does not use a server” sounded like it was talking about native apps. There was a lot of swearing yesterday about how stupid it was for me to have to spin up a web server for the “serverless” option because I didn’t pick up that “does not have a server” and “for example, a javascript app” meant that by serverless it meant running in a web app locally.
Similarly the DCGF description of “Use this if you have limited input capabilties” doesn’t convey that this is the only choice if you want to have a native app on a “traditional” desktop platform.
Something like “Implicit: Use this flow if you’re writing a app which can’t securely store client secrets or if your app can register its own custom URI scheme” and “Device: use this if you’re writing a native app incapable of rendering web content or registering a URI scheme”
But any flow can be used for any method just about. Theres no hard rule per sae. Other than if you can’t hide your client secret then you shouldn’t can’t use code flow, or any flow that requires a client secret to be used
Just different flows are more optimal for different use cases.
So with a server I can use DCF if I want, or I run stuff inside the client side as I don’t need to make calls on my server on behalf of the user.
So any given flow can be used for a bunch of different use cases.
Just a given flow is better optimised.
So for your use case, if you don’t need the token in your server backend code you can do all your API calls in JS inside the Client without touching your server.
So you could use implict auth.
Both Implict and Code flow (for tokens and OIDC) is the same UX.
Show link, user clicks link, user accepts (or decliens acces), then you get back tokens or a code to exchange for tokens
DCF is different due to the code thang
and Client Creds is server to server comms (no UX)
I realized the thing it was getting at from the mobile perspective later, I’d not thought about the URI scheme trick when I was first forming the thought. I’d consider that flow but doing scheme registration is a lot more annoying than putting something in the user’s clipboard.
The UX is generally the same, but I considered implicit superior because all you have to do is click. Device code is a bit more annoying (though I can always just put the code into their clipboard for them.)
Yeah, my only options were DCF and implicit in this case. I’m working on a little stream pet that’s fed with redeems I grab over eventsub, so there’s no “server” component at all
So Eventsub websockets, so yeah thats implict auth.
So JS would grab the token to use and away it goes
The hard bit is still needing a page to return to do get the token (hence the redirect URI),
or you can have the UI open a new window to auth with and Post back the token (assuming your solve cross domain) or have the user copy/paste the token in if you can’t redirect
And Client Side grabs and goes.
Or you manually copy/paste in the token to use from another page. (sorta like how some of my github examples work where you either implict in or can provide an existing token to use)
So DCF might work here too anyway. That doesn’t need a server to go where public client ID can do all the work on DCF
Yeah msot auth needs a server to at least host the files
So if personal use copy/paste the token in might be the way to go.
But you have to redo every 60 days when the token dies if hard coding that.
