I'm building a vue js web app and I would like to make respective calls to the to my prismic repo, but I don't know how to do it without exposing my access token. I am using the rest api approach shown here.
Any ideas?
The http request syntax is as follows. I want to do this inside my vue components while not exposing the access_token.
http://your-repository-name.prismic.io/api/v2/documents/search?ref=Your_Ref&access_token=Your_Token
In my API/Security settings I'm also given a Client ID and Client Secret. I can't figure out how I can use these either.
Thanks
You'd have to store your access token on your server and make it process the requests on behalf of the client.
In the end, you'd send requests to your server instead of directly to prismic.io, your server will then send the access token authorized request, fetch whatever you need and return it back in response to the client.
The work flow would look like this:
Client sends request to i.e. http://localhost:8000/api/endpoint
Server sends request to prismic.io endpoint associated with the above endpoint.
Server gets prismic.io response and sends it back to the client.
Client gets the response.
If you want to hide your access token client-side, then it's impossible. To protect your access token the other two options are:
Make users use their own prismic.io access tokens.
Allow access only to authorized users.
The two options above are probably not what you want, so setting up a proxy server is what's left.
Related
It is my understanding that, as someone that has recently started using JSON web tokens that, once an access token expires, a new one may be generated using a refresh token.
I currently have some middleware on my server configured such that, if a JWT verification fails, it uses the refresh token to generate a new access token and then attempts the verification process again. If this succeeds, it sends a response with the new access token attached. If it fails, it sends a 401 error.
For this to work, however, the client must send both the access and refresh tokens. My fetch requests are currently configured such that they send the access token under the Authorization header as Bearer [token].
However, when reading the JWT docs, I have come across nothing that refers to the correct manner in which to send the refresh token. A brief search returned that it should be sent in the body of a POST request, however, given I am currently sending both tokens in all fetch requests I make, this would not work for GET requests.
Should I be sending both tokens in all requests? If so how should I send the refresh token in a GET request. Given it is stored in the client cookies, I have considered extracting it from there, though I'm curious if there is a better/more generally accepted method.
I have client-side login on my app which is working just fine. Now I need to pass the clients UID to Node.
Found this Verify ID Tokens in Firebase docs, but i just don't know how would i actually do this part: "Send token to your backend via HTTPS"
Does your Node server-side piece have an API already created, or do you need to build that?
There are many ways to pass this information from the client to the server. Sometimes auth information is passed in an HTTP header of an API call that does something else. Sometimes APIs include a specific call to "register" a user with the backend, where you would pass the client-side token to the server in the payload of that one call.
There is no single best way to pass the client user authorization information to the server, every application needs to make that decision as part of their server-side design.
We offer a web service, where a user can execute a POST request and get HTML. This is done server to server. The post that is sent with the request data includes his secret key, and other parameters.
We want to allow for this to be loaded via AJAX. So the request will be done client side, after the page has loaded. This way, no server side implementation will be required to install our service, beyond a slight modification to output the script.
We are not sure how to secure this operation, because we can not output the secret key as a JavaScript parameter (it is exposed that way). We usually use a user ID + apiKey combination to authenticate the request when it is don't server to server.
We know the users's key, and their valid domain, so if there's a way to make absolutely sure the domain that is sending the request cannot be faked, it may also solve our issue.
How can we make it so that we can differentiate requests coming that way, without exposing our secret key, so that we may provide the information only the authenticated requests?
I'm working on a javascript application using a REST API.
Authentication is made with JWT tokens stored in cookies
Right now, this scenario is implemented:
user sign in with credentials. Client calls POST /token to authenticate
server responds with a HTTP-only cookie containing the token.
once authenticated, client makes another request to get all user data (GET /me)
I would like to make this process as fast as possible and reduce the number of server requests as much as possible. I thought about combining /token and /me calls and get token and user data in the same request.
That could be done in different ways :
in the claims of the token, but client won't be able to use it as it's in a HTTP-only cookie.
in another, non HTTP-only, cookie but that will be sent uselessly with every future request, so I don't like this solution
in the response body when server sends the cookie after authentication but I have the feeling that it goes against the REST principles as we send user data from an authentication endpoint.
Is there a way to make this process more simple while respecting standard processes and REST principles?
I personnally use Cookies as a storage, but not in HTTPonly mode. In this case, the simplest is to encode the information you need inside the token.
Are you forced to use HTTP-only cookies? Is it an option for you to change it (in fact, for that you must master the authorization server)?
Another thing : using GET to pass credentials isn't safe as you probably pass your credentials in the URL, which can be fetched from server logs. Prefer POST (and HTTPS of course).
Few pointers about JWT and their storage stategies:
Tokens vs Cookies
Where to store the tokens?
Threats of token theft
How to send the JWT to a client just after client has authenticated without using Cookies when an html document body is needed to be sent too?
There are docs, blog posts, and tutorials, explaining the cookie-less jwt authentication and leveraging the use of Web Storage API to save the jwt client side. But all of them are trivial examples without sending an html document in http response body upon an authentication which is necessary in some real world applications I can imagine. A cookie can be sent in cookie http response header alongside with an html document in same response's body, I could not still come across a post explaining to do this with a jwt in response instead of a cookie. As I know there is not an API to reach the response headers from javascript in browser if one want to send the jwt in response headers alongside html document in response body.
I have handled your scenario in my project and it can be done in two ways depending on your technology stack you are using and environment constraints, and using OAuth is not mandatory.
Method 1
Send the JWT embedded in the HTML page as a tag. It wont be rendered on the page but can be parsed by you. However, it will be visible in the source window of the browser but it doesnt matter as that would be a protected page and once the next page is rendered, it will not be available.
Method 2
You can send the JWT in a cookie for the first time with a http-only constraint. Handling it over https would bring in extra leverage. Also, like you mentioned, you can delete the cookie.
In case you are using AngularJS on your client side, you have the provision of securing cookies by restricting XHR from the same domain which would avoid the extra task of deleting the cookie.
In fact, #user981375 was mentioning about redirection which can be handled too by Method 1 above. In my case, server provided the redirection URL after successful login however, ajax wouldnt be able to see a 302 header instead would see a 200. So we intercepted that part on server and embedded the token into the 200 response page, i.e. redirected page which is parsed by the client.
I'm in the same boat, I could not figure out how to send JWT token to the client upon successful (or not) social login(s) where redirect was required. Things are simple when when you present user with a login/password and authenticate against your own server via AJAX, but no so simple when you 1) load your login page, 2) do a redirect to OAuth provider, 3) callback to your own server, 4) issue your own JWT token and ... then what?
There is a library out there that provides OAuth support from the client side. You authenticate against Facebook/Google (whatever) get their token back and then you make AJAX request to your own server for token validation. When token is validated by Facebook/Google (whatever) you can then issue your own JWT token with claims and send it as a response (AJAX) to your webpage.
Here is the library and nice article describing how to use it.
HTML documents are usually retrieved from a web application. Web applications are protected by a form of implicit authentication.
Web APIs are usually protected by explicit authentication and the JWT tokens are sent in an HTTP header (Authorization). This is not done automatically by the browser. You have to do this explicitly through JavaScript.
You could of course store the JWT token in a cookie and have it automatically sent to the server on each request.
See also my answer here.