I am completely new to O-Auth but I have just implemented my first O-Auth flow in obtaining access tokens from an external API to gather information on users using NodeJS and Express. The external API generates an access token and a refresh token as the access token only lasts for 24 hours.
I am wondering what is the best practice to store API access and refresh tokens as I will have to use them even when the user is not accessing my application to gather information in the background. Would it be just a database and then querying the database on the server side of my application to access the API? Then refreshing the token and updating the entry from within the database?
Any advice is welcome!
The answer really depends on the type of API client you are using. OAuth has standard solutions for the below 3 scenarios. As a next step, maybe let us know which of these scenarios is closest to yours:
Web UI: gets tokens for an end user, stores then in memory, can deal with access token renewal via cookies
Mobile UI: gets tokens for an end user, can store them in OS specific secure storage
Back end process: gets tokens on behalf of itself, stores then in memory and re-authenticates when tokens expire
I would aim to leave token storage to the Authorization Server, which has built in processes to do this in a secure manner.
Risks with a second token store are that a rogue employee could perhaps grab tokens and operate as users - so it is worth thinking about this kind of threat.
Related
On most of the JWT (JSON Web Token) tutorial (e.g: this and this) are saying, once validated you can use the incoming token to get client information without validating it from the DB.
My question is, how invalid user situation is maintained then? What I mean is, lets say a client just got a JWT token which expires in one week. But for very specific reason lets say we decided to invalidate the user, and don't want the user to access our API. But still that user has a token which is valid and user can access the API.
Of course if we take a round trip to DB for each request then we can validate if the account is valid or invalid. My question is, what is the best way to take care this kind of situation for long lived tokens.
Thanks in advance.
It's difficult to revoke JWT-based access tokens if not impossible.
How should an access token be represented? There are two major ways.
As a meaningless random string. Information associated with an access token is stored in a database table behind an authorization server.
As a self-contained string which is a result of encoding access token information by base64url or something similar.
A choice between these ways will lead to consequent differences as described in the following table.
See "7. Access Token" in "Full-Scratch Implementor of OAuth and OpenID Connect Talks About Findings" for pros and cons of the ways of access token representation.
If your access tokens are JWT-based, your system has to (1) remember revoked access tokens until they expire. Another compromise is to (2) make lifetime of access tokens short enough and give up revoking them.
Personally, after consideration, I didn't select JWT as access token representation when I implemented an authorization server (Authlete) because it is difficult/impossible to revoke and update JWT-based access tokens once they are issued.
RFC 7009 specifies OAuth 2.0 Token Revocation. Basically you have an endpoint where you can revoke the access_tokens.
It's not clear which OAuth flow you are using from your question, or whether you are referring to OpenID Connect rather than Oauth.
Consider using refresh tokens and have a much shorter expiration on your access token - e.g. 30 mins.
In this scenario, the user (resource owner) doesn't have to keep authenticating, and your API (Resource Server) doesn't have to check the user is still valid on every single request.
Once the access token expires, your client (application calling your API) should contact your DB (Authorisation Server) and exchange its refresh token for a new access token - and usually a new refresh token - providing the user is still a valid user on your DB and the user has not revoked access for the client application to his/her data on the API.
You could also use token revocation as suggested in another answer if your Authorization Server allows it but I would try refresh tokens and short-lived access tokens as it's much easier to implement and doesn't pollute your API with user authentication/authorisation concerns - this job is best done by an Auth Server.
That's the main problem when you are using JWT. So basically best approach in this case is creating blacklist on your gateway. It's not best solution for security point of view but this is only good solution if you are using JWT.
I am building an Authorization Server in terms of OAuth 2.0.
There is also a 3rd party web application (Client) which is using my Authorization Server. It's a regular web application, and the user may have several active sessions established with this application (for example, office and home machine, or just several web browsers on the same machine).
My Authorization Server issues an access token #1 (with or without the refresh token, that's not so important here) for Client once. When the user starts a new session with the Client, should the Authorization Server give the Client app the same access token #1 for that new session or should it issue a new #2 token?
My thougts:
From security point of view the new token might sound better, but then if the user wants to manage his authorizations, he will see a separate entry for each Client session, which might be messy.
For example, GitHub returns the same token for previously authorized clients, and on the "applications" page in my GitHub account I see only one entry per application, no matter how many sessions I've started, which is convenient.
However, this approach means that I have to store access tokens in Authorization or Resource server in the reversible way (plain-text or encrypted with some known key) instead of using irreversible hashing (like you usually do with passwords, storing salt and password hash from bcrypt, pbkdf2 or something similar).
Please be advised that I am not a security expert and this explanation
is my general idea of oauth. Reason why I mentioned this in the
beginning is because I see you are CREATING YOUR OWN AUTH SERVER based
on oauth 2.0 protocol, which means down the road some people might be
using your server for authentication, and thus I don't want you to
have the wrong concept.
The session-oauth mismatch
I want to clear this first that don't mix sessions and oauth. These are two separate things usually found working together IMHO.
Oauth protocol simply gives the apps/users with an access token via which the app/user can query your server for data associated with the token.
Session on the other hand depends on the application itself. Once some app received the token, they make a session out of it. When user logs in or logs out, the session is destroyed, not the oauth.
So what is the fate of oauth token?
Well from a server standpoint, each of your token should expire after a certain time period. That is it. Server does not know anything else. It gives you the token, then expires it after 'n' seconds.
However, the app may decide that it wants to revoke the access token. Maybe their website was hacked, or maybe they are done with all api calls. Then they can send a special request to your server telling you to force-expire the token.
So what should I do about user opening multiple sessions?
ABSOLUTELY NOTHING. As an oauth service provider, you are not concerned with sessions at all. All you know is that if the app asks you for a token, you give them one.
However, I will answer you question about sessions as well. Should you spawn different sessions for the same user? I would say yes. If you have same session, then if you log out from one machine, and refresh the page in second machine, since the session has expired, your other browser/machines will also log out naturally.
So how does github manages to not show extra entries?
Well I do not work for them so I don't know. But I guess that they will check each session, and if two or more sessions are associate with the same user, they know the user must be using many devices. Then when one of your devices sends some request to github, they can guess from the IP address your location, and if many of your machines are making requests from same place, you got to be using multiple machines. If not, then maybe some attacker is using your account as well.
This is how AFAIK banks predict malicious users - well not the only way, they sometimes also predict the pattern you are using to access bank records, and if that pattern is different, there are good chances that your account was compromised.
So now you may ask me, are you really sure that I should create as many tokens as the app demands me?
This is the part where I am not so sure. From what I have seen, oauth has two things. Google these two terms for more info:
Refresh Token: This token is not your access token. This token never expires, and once your access token is expired, you can use this token to get a new access token. This token is also to be kept secret.
Offline access type: Many oauth providers such as google and facebook also support this mode. This mode basically allows you to extend the expiry time of your access token. E.g. instead of normal expiry time of access token (e.g. 1 hour), for offline tokens you might have the expiry time of 1 year or so.
Answer to the question "Should I reuse OAuth 2.0 access tokens?"
Yes, the token is supposed to be used as many times as you need within the given expiry time (google sets it to 1 hour).
After it has expired, use the refresh token to get another access token and use it as many times as you need. Keep repeating the process.
If your users won't be online for you to start the oauth process, and you don't have the refresh token, then the app needs to have "offline" tokens.
Should I store my auth tokens?
You can if your app demands it, but it is nowhere recommended because of the potential to be leaked. Tokens are supposed to extract data within the given time limit and reissue the token when needed again. However, you surely can store them if you want.
"Offline" tokens, on the other hand, are expected to be stored. You can encrypt them if you like, but if the scopes are not too broad, I wouldn't bother at all.
I am looking to using OAuth to secure some web services. OAuth 2 fits nicely for the use cases I have where the user might access his/her own data using API's or grant access to someone to call API's on his behalf.
However, the initial set of API users are not very technical and they would not want to go through the effort of making API calls just to generate tokens. I am thinking of implementing the following solution but am not sure if this is the right way.
If the user is a developer, then
Have a screen where he/she can register an application. This will generate an API key/secret pair.
To access his/her own data (For 2 legged Auth) have a UI screen where the user can generate a access token for one his registered applications. He can specify the scopes and duration in the form.
If he is a 3rd party developer, then he needs to pass his applications API key to the person on whose behalf he needs to access the API and get an access token in exchange.
If the user wants a another application/developer to access API's on his behalf then
Have a screen where he can enter the third party's API key, scopes and the duration of the authorization. He can pass the generated access token to the developer who'll access the API's
I am going to use same OAuth libraries to generate the token that I would have used if I had gone the web service route. Further, I can also develop services whenever the current situation doesn't scale or the need arises and the existing tokens would still work.
The problem is mainly one of security. By design, duration of access token should not be set by a client. If someone else gets to know the access token and client id during this duration, this user's account will be compromised. Normally this duration is set to be not very long and a second secret value refresh token is used to refresh the current access token. The token refreshing can be automated in code, but in your approach it will need to be done manually.
I'm playing around with the api of a service that supports oauth. I managed to retrieve the access_token from the service and I'm now able to call the various endpoints of the api. So far so good.
Now my question is: How long do I hold on to this access_token I received. Is this a token I keep forever, or does this expire after some time? I'm working on a desktop app, so I a have two options:
I request a new token every time the application is opened
I store the token somewhere and re-use it
What are the best practices around the storage of this token?
Usually the Access Token is stored across sessions. There is an expiration (with OAuth 2.0), but the Refresh Token is then used to retrieve a new Access Token. If you don't store the tokens, then you would need to have the end user re-authorize everytime they want to use your application (which is probably not the experience you are looking for).
I want to understand what token-based authentication means. I searched the internet but couldn't find anything understandable.
I think it's well explained here -- quoting just the key sentences of the long article:
The general concept behind a
token-based authentication system is
simple. Allow users to enter their
username and password in order to
obtain a token which allows them to
fetch a specific resource - without
using their username and password.
Once their token has been obtained,
the user can offer the token - which
offers access to a specific resource
for a time period - to the remote
site.
In other words: add one level of indirection for authentication -- instead of having to authenticate with username and password for each protected resource, the user authenticates that way once (within a session of limited duration), obtains a time-limited token in return, and uses that token for further authentication during the session.
Advantages are many -- e.g., the user could pass the token, once they've obtained it, on to some other automated system which they're willing to trust for a limited time and a limited set of resources, but would not be willing to trust with their username and password (i.e., with every resource they're allowed to access, forevermore or at least until they change their password).
If anything is still unclear, please edit your question to clarify WHAT isn't 100% clear to you, and I'm sure we can help you further.
From Auth0.com
Token-Based Authentication, relies on a signed token that is sent to
the server on each request.
What are the benefits of using a token-based approach?
Cross-domain / CORS: cookies + CORS don't play well across different domains. A token-based approach allows you to make AJAX
calls to any server, on any domain because you use an HTTP header
to transmit the user information.
Stateless (a.k.a. Server side scalability): there is no need to keep a session store, the token is a self-contained entity that conveys all the user information. The rest of the state lives in cookies or local storage on the client side.
CDN: you can serve all the assets of your app from a CDN (e.g. javascript, HTML, images, etc.), and your server side is just the API.
Decoupling: you are not tied to any particular authentication scheme. The token might be generated anywhere, hence your API can
be called from anywhere with a single way of authenticating those
calls.
Mobile ready: when you start working on a native platform (iOS, Android, Windows 8, etc.) cookies are not ideal when consuming a
token-based approach simplifies this a lot.
CSRF: since you are not relying on cookies, you don't need to protect against cross site requests (e.g. it would not be possible to
sib your site, generate a POST request and re-use the existing authentication cookie because there will be none).
Performance: we are not presenting any hard perf benchmarks here, but a network roundtrip (e.g. finding a session on database)
is likely to take more time than calculating an HMACSHA256 to
validate a token and parsing its contents.
A token is a piece of data which only Server X could possibly have created, and which contains enough data to identify a particular user.
You might present your login information and ask Server X for a token; and then you might present your token and ask Server X to perform some user-specific action.
Tokens are created using various combinations of various techniques from the field of cryptography as well as with input from the wider field of security research. If you decide to go and create your own token system, you had best be really smart.
A token is a piece of data created by server, and contains information to identify a particular user and token validity. The token will contain the user's information, as well as a special token code that user can pass to the server with every method that supports authentication, instead of passing a username and password directly.
Token-based authentication is a security technique that authenticates the users who attempt to log in to a server, a network, or some other secure system, using a security token provided by the server.
An authentication is successful if a user can prove to a server that he or she is a valid user by passing a security token. The service validates the security token and processes the user request.
After the token is validated by the service, it is used to establish security context for the client, so the service can make authorization decisions or audit activity for successive user requests.
Source (Web Archive)
Token Based (Security / Authentication)
This means that in order for us to prove that we’ve access we first have to receive the token. In a real-life scenario, the token could be an access card to the building, it could be the key to the lock to your house. In order for you to retrieve a key card for your office or the key to your home, you first need to prove who you are and that you in fact do have access to that token. It could be something as simple as showing someone your ID or giving them a secret password. So imagine I need to get access to my office. I go down to the security office, I show them my ID, and they give me this token, which lets me into the building. Now I have unrestricted access to do whatever I want inside the building, as long as I have my token with me.
What’s the benefit of token-based security?
If we think back on the insecure API, what we had to do in that case was that we had to provide our password for everything that we wanted to do.
Imagine that every time we enter a door in our office, we have to give everyone sitting next to the door our password. Now that would be pretty bad because that means that anyone inside our office could take our password and impersonate us, and that’s pretty bad. Instead, what we do is that we retrieve the token, of course together with the password, but we retrieve that from one person. And then we can use this token wherever we want inside the building. Of course, if we lose the token, we have the same problem as if someone else knew our password, but that leads us to things like how do we make sure that if we lose the token, we can revoke the access, and maybe the token shouldn’t live for longer than 24 hours, so the next day that we come to the office, we need to show our ID again. But still, there’s just one person that we show the ID to, and that’s the security guard sitting where we retrieve the tokens.
The question is old and the technology has advanced, here is the current state:
JSON Web Token (JWT) is a JSON-based open standard (RFC 7519) for passing claims between parties in web application environment. The tokens are designed to be compact, URL-safe and usable especially in web browser single sign-on (SSO) context.
https://en.wikipedia.org/wiki/JSON_Web_Token
It's just hash which is associated with user in database or some other way. That token can be used to authenticate and then authorize a user access related contents of the application. To retrieve this token on client side login is required. After first time login you need to save retrieved token not any other data like session, session id because here everything is token to access other resources of application.
Token is used to assure the authenticity of the user.
UPDATES:
In current time, We have more advanced token based technology called JWT (Json Web Token). This technology helps to use same token in multiple systems and we call it single sign-on.
Basically JSON Based Token contains information about user details and token expiry details. So that information can be used to further authenticate or reject the request if token is invalid or expired based on details.
When you register for a new website, often you are sent an email to activate your account. That email typically contains a link to click on. Part of that link, contains a token, the server knows about this token and can associate it with your account. The token would usually have an expiry date associated with it, so you may only have an hour to click on the link and activate your account. None of this would be possible with cookies or session variables, since its unknown what device or browser the customer is using to check emails.