I am wondering if it is allowed to send tokens created with the Implicit Code flow to my server to verify that a user is logged in with twitch.
My (web-)application runs almost entirely within the user’s browser, but there is one endpoint on my server for which I want to make sure the user is actually logged into twitch. I don’t need to store any user data on my server (or make requests on the user’s behalf), I basically just want to have my server send the access token to the validate endpoint to make sure that they are logged in (to reduce spam on an unauthorized endpoint).
Is this sort of thing allowed? The way I understand it, the Implicit Code flow does not require a server to use the token, but the documentation does not state that it is disallowed to ever send the token to my own server.
Because I can make the server completely stateless at that point even without doing any kind of JWT stuff. It’s just less code for me to write and it will also make everything easier to maintain, when I don’t have to worry about token invalidation in two places (app ↔ my server, my server ↔ twitch) instead of just one (app ↔ twitch).
JWT doesn’t apply to oAuth o.0 (unless you are doing OIDC which is a different matter)
If someone oAuth’s into my server, the token only exists in the server, and I use a session. So if I invalidate the token (or find the token is invalid), I just murder the session, logging them out of my website. (most likely the same amount of code)
But your work flow is perfectly valid, passing the token to your server then to the API, is basically the same as calling the API in the first place.
You basically just have an API proxy (handy if you are gonna call IGDB which has CORS headers in the way to block front end requests)
Nothing wrong with it, just odd to do it this way to me!
But if I used a session, I would need to keep even more state, and probably even have a DB in the loop. If I used an encrypted JWT between the app and my server which would store the access token I get from twitch, I could still keep everything stateless, but I would have to worry about invalidating that JWT as well. I’m basically trying to avoid a session system (or storing “session data” on the client inside a JWT) and keep most of the app’s functionality within the browser if possible (which makes sense for the kind of project I’m working on, trust me )
Yes exactly! That way, the website can communicate with twitch directly and do most of everything it needs without my server being present, but if it is it can prove to the server that a user is logged in and then access additional functionality that requires some server-side stuff.
A JWT is a public token, you can decode it on any system. You can only validate it if you have the secret key. I have been doing what you mentioned for years for my bot. I use the oauth token to validate the user is who they say they are, then create a JWT for the rest of my auth processes to keep them logged into the system, and they have to re-login every 60ish days. I’m now just converting to an auth flow system but very similar setup, i’m sending the code to the server to auth who they say they are, then supplying a JWT for app auth.
Well sort of, there are two types of JWT, JWS (signed tokens) and JWE (encrypted tokens). Since the twitch API assumes that “a server can securely store a token” I would probably not want to have it in a form that the user can decode/decrypt, even though I technically wouldn’t be storing it on the server in that case.
I don’t store the access token in my JWT at all, it has nothing to do with my auth system. I just use it to validate who they are, then generate a separate auth jwt completely. The token is stored in the database
Yes I know how a session works, lol. It’s just that for my usecase, I wanted to have something completely stateless, i.e. no database, no session, no nothing, so storing it on the user’s device in an encrypted fashion would be the only option. I’m not really sure what your point is anyway? My question got answered and the way I’m doing it now works perfectly fine (i.e. just send the access token to the server with each request to prove that the user is logged in with twitch and authenticated with my app).
)