Plaid and security newbie here.
From what I understand, access tokens are valid indefinitely, granting the user access to information regarding one of their accounts.
Each account possesses a unique access token, and the tokens can only be invalidated either through the 'delete' request or through a user changing their password for that specific bank/account.
I'd like to keep them secure, and reduce the risk of them being accessed by hackers/nefarious actors, etc.
What would be the best way to store them though?
From what little I know, it might be best to keep them in the backend and use them when needed to access user data on request, then send that resultant data to the frontend (with other protections in place like verification and authentication of the user).
Is there a more secure way to store them? Perhaps to encrypt them between calls?
And a follow-up, any thoughts on storing these tokens in something like Supabase? From what I've read and seen, Row Level Security might help mitigate some of the risk, no?
Your general thinking seems right to me -- access tokens should be stored in an access-controlled database on the backend and never stored on the client side. Encrypting access tokens at rest is recommended but not required. As you think about your security model, note that that the access token alone doesn't grant data access -- the access token + API client ID + API secret key combination is required for data access.
Related
Client sends username and password to the server.
Server then checks if this user is authenticated.
If yes, the server returns an access token for the client...
Then user can use this access token to access protected resources...
The advantage here, is that we are not sending user info via API calls, and the access token will not last for long time, so hackers won't be able to find out user authentication info (user name and password), and if he finds out, the access token won't last long enough to do anything with it.
That's how I understand Laravel passport API security.
The confusing thing here, is that on first API call, user has to send user name and password, so hacker still have big chance to find out user info!!!
I know that there is something wrong with my understanding, and that's why I get confused, any explanation would be very appreciated.
There must be a way to prove your identity to authorization server, and one way is to provide username and password. The way you're gonna achieve communication between authorization server and your client application is totally up to you as long as it uses HTTP. As stated in RFC-6749:
This specification is designed for use with HTTP ([RFC2616]). The
use of OAuth over any protocol other than HTTP is out of scope.
Of course it's always advised to use HTTPS whenever possible. Just because HTTP is mentioned in document, doesn't mean HTTPS cannot be used because HTTPS is just encrypted version of HTTP.
Other thing I wanted to mention is that you don't need to provide username and password, there are several grant types where you can, for example, instead of username and password you can provide client_id and client_secret which is used in Client Credentials grant type.
If you are new to this I believe this all is little bit confusing for you. To summarize the purpose of OAuth2 to you (as far as I get it), is:
To separate role of the client (which can be browser, mobile etc.) from the resource owner (usually the owner of account). Why? Because if there is no separation, the client has access to user's sensitive data.
Imagine that the first point is secure enough for communication. But what happens if someone gets their hands on the session you have? They have access to all! This is why OAuth introduces scopes, where depending on the scope user has with provided access token has limited access to resources. Scope can be read, write, share etc. - this implementation is up to developer. So if someone gets their hands on your access token, because of scope they only have a limited access to resource.
These are one of my reasons, while RFC-6749 has better explanation:
Third-party applications are required to store the resource
owner's credentials for future use, typically a password in
clear-text.
Servers are required to support password authentication, despite
the security weaknesses inherent in passwords.
Third-party applications gain overly broad access to the resource
owner's protected resources, leaving resource owners without any
ability to restrict duration or access to a limited subset of
resources.
Resource owners cannot revoke access to an individual third party
without revoking access to all third parties, and must do so by
changing the third party's password.
Compromise of any third-party application results in compromise of
the end-user's password and all of the data protected by that
password.
To learn more about OAuth2, it's grant types and purposes, I recommend you to read this:
An Introduction to OAuth 2
Mentioned RFC-6749, even though it can be difficult to read because of technical writing.
Hope I clarified at least a small piece of blur.
I have started building a C# asp.net website that will have the ability to post directly into Yammer (we have Yammer Enterprise). I have used the REST api to create a post and have also been able to create in impersonation token to post on behalf of other users. It works fine, but reading the documentation, the tokens seem to have an indefinite lifetime. Forgive me is this is a stupid question, but is there an expectation that as a developer, I should store the token locally (eg in a SQL table) and reuse local version for future API calls?
If the API call fails, then I assume I regenerate the token and re-store for future use?
Thanks
Andy
Yes, these tokens don't expire until an account is suspended or deleted in Yammer, or the user manually revokes the app. Until that changes you need to be very careful with handling these tokens. Applying encryption, permissions, and other techniques to secure your app is the best way to protect them.
You might also consider storing the time when the token was acquired or last used. Then delete the token after a period if it hasn't been used. That will protect the user.
In your UI make it clear what your app does with Yammer so that users authorizing it are aware of what they are opting into.
I'm a little new to this and please bear with me if I ask dumb questions.
As what I know, session is something saved at server (either in file or in database), and client access it via sessionid saved in cookie. To keep user login information, we can simply put a 'logged_in' column and an 'expired' column in session file or session table.
As far as I know, Oauth2.0 is designed for third party client to access the server. The whole process is controlled by an access_token, which is quite similar to sessionid (at least from my knowledge).
So, here's my question, is it possible to use Oauth2.0 to completely replace session? I.e., even people are using the website designed by me (NOT third party website) to access my own server? So that I have a unified authorization framework for user accesses both from my own website and any thrid party website.
Is there any pros&cons of using session & oauth 2.0?
Lastly, how about mobile app? I know for third party mobile app, they normally use oauth to access the server (many websites provides oauth api). How about if I am going to write my own app for my own server (NOT third party)? Does Oauth 2.0 apply here too?
To summarize, my question is actually is, is Oauth 2.0 universal that can be used in all kinds of user authorization control situations from all kinds of devices?
Thank you very much.
Though both are short-living entities, session IDs and OAuth tokens are fundamentally different and used for distinct scenarios. A session is used to identify a user of a web application, thus related to the end user. An OAuth token is used to grant access to a third-party service to access a limited set of protected user resources (e.g. read user contact information or send a mail from the user account). Though the token refers to the granter (i.e. end user authorized the grant), the token related more to the third-party application.
To give you an analogous example: imagine that you have a safe at your bank (i.e. your protected resource). The session is your id for the bank: give it to someone else and he will be you, he can get everything from your safe. On the other hand, a token is a limited authorization to someone else to your safe: e.g. your approval that he can get 10$ from your safe while a security guard is watching.
As a summary, sessions and tokens are not interchangable.
I'd like to secure access to resources in my web application, so I authenticate my users using the standard mechanisms and use server-side sessions to preserve the authenticated state.
I'd like to deploy across multiple systems in a load balanced configuration, but I don't want to start synchronising session state across my infrastructure. Are there ways (using either spec-driven facilities in Java EE or commonly available libs like Spring Security) of preserving the authentication state of a user without server-side sessions, for example by pushing the required state back out to the client? If so, are there additional risks I need to be aware of?
Update - I am using declarative security as per Java EE webapp specs and authenticating via an LDAP repository.
I'm not aware of a framework solution, but the following does work:
After the user successfully logged in you create a secured token and set it's value as a cookie. The token contains all information required (user ID, creation time, etc.) and is encrypted using some algorithm. So all nodes in your cluster can read the token, decrypt it and identify the user. Then you create a ServletFilter intercepting all requests, examining the token and set corresponding user credentials for e.g. ServletRequest.getRemoteUser() by using an HttpServletRequestWrapper.
One way to solve the problem. But you must take care, self-made security must be well-thought-out.
You can store some kind of token in a cookie after authentication, and manage session attributes yourself. E.g., have a database table whose primary key is the authentication token and stores user session data... Don't forget to implement a job to clean inactive "sessions".
As for what you should be aware of, keep in mind that cookies are something easy to access, steal, delete, disable, etc. The authentication token should be something strong and verifiable (hash a combination of the user ip + browser + rotating salt + some other things you can check for).
It is also wise to divide user authentications in two levels. "Has the cookie" and "just validated the cookie"... Let's say that "has the cookie" is a state that can be there for half an hour (or maybe more) which allows the user to navigate the site. "Just validated" state is for important operations, and should require the user to enter it's credentials again. The timeout for this "just validated state" shouldn't be much longer than a couple of minutes.
Keep in mind that I'm assuming that your site is not holding really sensitive data. For those situations I would recommend something such as two-way SSL authentication with external tokens or security cards plus rotating token devices plus biometrics authentication :D:D:D... I guess you see my point.
Cheers,
You can use an open id server to authentication thus separating your authentication and application logic.
I just started looking into OAuth and it looks really nice. I have oauth with twitter working in ruby right now.
Now I'm wondering, what is the recommended safe way to store the responses in my local database and session?
What should I store?
Where should I store it?
This example twitter-oauth-with-rails app stores a user.id in the session, and the user table has the token and secret. But that seems like it'd be really easy to hack and get the secret by just passing in a slew of test user ids, no?
The tokens are useless without the consumer key/secret of your twitter app as they're not the same for every app but depend on the consumer key/secret.
To get a session variable you would have to guess the session id which is not that easy to accomplish.
If you want you can store those tokens in the session but I would suggest storing the user tokens in your database with all the other user data so your session contains only the data to identify the user in your system.
Update: I'm not sure if I understand correctly what you mean by accessing the tokens from the database by guessing an ID.
Do you have any authentication in place so that the users have to enter some credentials to access their data? You should store the tokens the same way you store the users email address or password and only authenticated users should be able to access it.
If you're developing a web application you can add a hidden field to the form the user submits, with some hash-like value calculated with the user.id so evil guys cannot change that value and just "guess" for an access token