I'm quite of new about issuing access tokens and I would like to know if any of you can help me clearing my question.
Is it considered a best practice to use only the access tokens at the server-side? I saw a tutorial of authorization flow in which this guy was passing the token through the hash(#) in URL, but this seems to be really insecure since it's available to the user.
On the other hand, how do you manage access token usage? I can think of two approaches.
Passing the access token to the client and storing it using an encrypted cookie since I read that localStorage is not recommended.
Using the access token only in the server-side and call the API endpoint from client. Thus, managing all data in server-side and returning to client the "final result".
This questions is kinda newbie but I'd love to read your opinions. Also I would appreciate if you can share any resources (videos, books, blogs) you think may be of help.
Thanks in advance
Related
I have implemented an OAuth flow where once users authenticate using google my Django backend creates a profile for them and also creates a JWT token for them to use to access some restricted API endpoints. The issue I'm currently having is how should I send the token to the frontend. Right now, I'm appending the token to the Frontend URL and redirecting the users to the frontend where the token is extracted from the URL and saved in local storage.
Is this a security issue and if so, how should I overcome it?
If you have a frontend which talks to your own backend, then I would consider using plain-old sessions with cookies instead of JWTs. Unfortunately tokens are never safe in the browser. You shouldn't keep them in the local storage as they can be quite easily extracted form there by any malicious code. It is safer to keep the token in the memory, but a more sophisticated XSS would still be able to steal that token.
I was recently hosting a webinar were we talked about the security of handling tokens in the browser and why we think you should stick to sessions: https://curity.io/resources/webinars/hardening-single-page-app-security. You can also have a look at this great video which dives into more technical details of attacks on tokens in the browser: https://pragmaticwebsecurity.com/talks/xssoauth.html
Still, if you want to stick to your solution a few things I would consider:
send the token in the fragment part of the URL. Thanks to that the token will be a bit more safe (e.g. won't be saved in history, etc.)
try to keep the token only in memory and avoid keeping it in local storage, unless losing the token isn't a real problem for your app (e.g. you don't have any personal information guarded by the token, etc.). I know that this requirement can be a bit more tricky when considering UX, as the token will be lost during a refresh of the page.
I'm new to backend development using Nodejs/Express and I'm creating an API in which registered users will be able to make requests to it by using an unique Access Token.
I'm already using JWT (JSON Web Tokens) for user authentication and after reading a lot of tutorials about JWT, I didn't find any explaining if it's possible to use JWT as Access Tokens (instead of as Authentication Tokens) or if there is another solution to generate this kind of token.
So, basically I have some questions about how to generate and use an Access Token:
Can I use JWT as Access Tokens? Is it safe? Is there another solution more commonly used?
How should I store the Access Token? Can I just save in the user model in the database so when I receive a request I just compare if they are equal?
When making a request, should I use HTTP Authorization header to pass my token or it's better to pass it in the URL (similar to Google Maps API: https://maps.googleapis.com/maps/api/js?key=YOUR_API_KEY&callback=initMap)?
So it's a quite broad question as it really depends on your app and the security you want to have.
If you are already using JWT tokens for login users and making sure they are authenticated that's great.
Now there are many ways you can make sure the user is authenticated in a secure way.
You can set an expired key inside the JWT, so it will be limited for 1 hour, 2 hours, a week whatever.
If you want the users to be able to log in only once you will need to dig a bit deeper into how you manage your tokens.
As for where should the user pass the JWT token in the header or in the GET params. So security wise it's similar both are accessible. But when you put the jwt in the url, there are limits to url length (I think 1024 chars)
For your specific questions on access tokens, not sure exactly what you intend to do with them.
But if it is just for providing other services to do actions on your api, so its better to store those access_tokens locally so in case you want to invalidate a key you could easily do that.
Short: How to authenticate and authorize role-based users in a microservice architecture?
Long: Say that you have the architecture given below.
I am struggeling to see what would be the best practice solution for securing such an architecture.
When i search i get alot of different answers.
"Leave authentication to a thirdparty OAuth provider". This seems like adding a lot of overhead and complexity for a rather simple application, and it may not be desireable to delegate authentication and authorization to a third party.
"Use JWT". If I am correct, then the use of JWT token is not suitable for external use (like in a SPA).
"Use a combination of opaque tokens externally and JWT internally linked in a redis/memchache". This seems like the best solution for my given situation, but my problem here is the lack of actual references to libraries/code examples.
I would higly appriciate if someone had some references of actual implementations to what i am trying to accomplish which would be:
Authentication, role-based authorization, in a microservice architecture.
There is not enough information to suggest what exactly should you be doing with architecture wrt authentication and authorization but I can tell you one of the approach that I tend to rely on.
Follow OAuth, as it gives you quite a few option, you can start with your own IDM/IAM and can later connect via social platforms.
We started of with JWT and for most part it was just a signed token (some time later we moved to signed and encrypted tokens). We created one service responsible for handling authentication and creating the JWT token. (We started with Keycloak but later moved to own service as keycloak was lil bulky for our use case)
When you say external, I am not sure what you mean by that, if is just accessible to end user IMO we can live with just a signed token. Yes all the information is visible to the user, but that is all his info and some authorization related information.
If you are passing your token to someone outside your boundaries, to an actual external system, where you do not want to share use information you can think of encrypting it, but then there will quite a lot of things that you need to think from security perspective and therefore going for either a standard security platform or a third party provider (whom both of you can trust and who puts enough thought in securing it) can help you in the long run.
Using the combination of an opaque token and JWT may be an overkill, unless you have a very strong reason against it. IMO you keep it simple to start with, make use of JWT through out, if required encrypt it. All you need will be one more service to manage authentication and creating and signing a token and you should be good.
So, I'm right now learning Node.js and I have few newbies doubts. I tried to search here and also in Google and I couldn't find my answer. I'm doing a Jwt Authentication and sending the token through header to my frontend which I'm rendering using handlebars as a view engine, my question is, how can I store that token and sending back through headers in every request? and What's the best way to do it?
Depending on chosen token expiration policy, you can choose different options. As previously said, token may be of course stored in localStorage.
The more secure option is keeping the token in memory. I would strongly suggest using short-lived JWTs and require them to be re-issued regularly (e.g. via an OAuth2 refresh token flow).
I have an app that offers an API. This app is an OAuth2 provider.
I want to access this API (read & write) with a client-side only app. I'm using JSO to make this easier.
It works great.
The thing is, I don't have to enter my client secret (of the application I registered in my app) anywhere. And I understand why, it would then be available to anyone.
So, if I can access my api without the client secret, could you explain to me what is its purpose?
This discussion provides an excellent explanation of why the client secret is much more important for server-side apps than client-side apps. An excerpt:
Web apps [server-side apps] use client secrets because they represent huge attack vectors. Let us say that someone poisons a DNS entry and sets up a rogue app "lookalike", the juxtapose might not be noticed for months, with this intermediary sucking up tons of data. Client secrets are supposed to mitigate this attack vector. For single user clients, compromise has to come one device at a time, which is horribly inefficient in comparison.
Client Secret was used in OAuth 1.0 to sign the request, so it was required. Some OAuth2 servers (such as Google Web Server API) required the client secret to be sent to receive the access token (either from request token or refresh token).
OAuth 2.0 has reduced the role of the client secret significantly, but it is still passed along for the servers that use it.
This was also driving me insane until I saw an example that made the answer blindingly obvious.
I have to be logged into The Server before The Server will return a token granting access to My stuff.
In other words, The Server will present Me, the human, with a login screen if I don't already have a valid login session with The Server. This is why explanations always say something like "it's up to to the server to authenticate".
Sure, The Server does not have to require that I am logged in. Is this realistic? Will Dropbox really grant access to My files to anyone without a login? Of course not. Most of the explanations I've read gloss over this point as if it doesn't matter, when it's practically the only thing that does matter.