I should probably make the assumption that anyone can see that code and make a request using whatever client e.g. postman.
Absolutely make this assumption. It’s that which makes me suggest using an HTTP-only, secure cookie: it defends it from code that knows what it’s looking for and where to look.
I think it's interesting you mentioned JWT. I'm going to do some reading up on that vs oAuth2.
This isn’t so much of a “vs” as two separate (complimentary) ideas. JWT is just a standard for creating and validating tokens. OAuth2 is a set of authentication protocols.
JWT is a totally logical choice for a token within an OAuth2 flow.
It’s not explicitly mentioned in the JWT docs but the recommended use of a JWT is in the Authorisation header, which is the same recommendation as in the OAuth2 Bearer spec (tools.ietf.org/html/rfc6750#sectio...).
I’m toying with a key design decision…
I won’t suggest anything specific but if there’s going to be a login form for the service, and an embedded login form, could they be the same form? (think iframes, CSP)
I'm wondering since I have only the user script to access data (via javascript) whether I can even access a http only cookie. I assume you need to read the cookie to send it in the subsequent API calls? Or do you send the cookie in the request and the server reads it?
It slurps up all the cookies for the origin it’s talking to and sends them along with the request automatically.
You don’t need your client side to be able read the cookie at all.
One other thing you could consider is writing a cookie that indicates that the user is logged in that can be read from JavaScript: that let’s you make decisions in your client-side code that don’t require “checking” with your API.
And I strongly suggest you don’t use local storage: you will have to write it against the origin of the game which makes it accessible to any and all other user scripts running.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Absolutely make this assumption. It’s that which makes me suggest using an HTTP-only, secure cookie: it defends it from code that knows what it’s looking for and where to look.
This isn’t so much of a “vs” as two separate (complimentary) ideas. JWT is just a standard for creating and validating tokens. OAuth2 is a set of authentication protocols.
JWT is a totally logical choice for a token within an OAuth2 flow.
It’s not explicitly mentioned in the JWT docs but the recommended use of a JWT is in the Authorisation header, which is the same recommendation as in the OAuth2 Bearer spec (tools.ietf.org/html/rfc6750#sectio...).
I won’t suggest anything specific but if there’s going to be a login form for the service, and an embedded login form, could they be the same form? (think iframes, CSP)
The first step is setting the cookie from the server, using the
Set-Cookieheader (developer.mozilla.org/en-US/docs/W...).After that, the browser does all this for you when you either (1) set
withCredentials = trueon the XMLHttpRequest (developer.mozilla.org/en-US/docs/W...) or (2) setcredentials: 'include'if you’re using the fetch API (developer.mozilla.org/en-US/docs/W...).It slurps up all the cookies for the origin it’s talking to and sends them along with the request automatically.
You don’t need your client side to be able read the cookie at all.
One other thing you could consider is writing a cookie that indicates that the user is logged in that can be read from JavaScript: that let’s you make decisions in your client-side code that don’t require “checking” with your API.
And I strongly suggest you don’t use local storage: you will have to write it against the origin of the game which makes it accessible to any and all other user scripts running.