I'm currently working on integration with Slack. The goal is to give a user the ability to share information using the Slack account right from our platform.
Since Slack uses OAuth2, we gain the access token on the backend (because of the app secret) and use it on the frontend. On the client-side, the token is stored in local storage.
Is it okay to store such tokens in local storage? The access does not expire itself, however can be revoked. P.S. the Slack application itself stores tokens in local storage.
Related
I have a mobile app which authenticates users on my server. I'd like to store images of authenticated users in Google Cloud Storage bucket but I'd like to avoid uploading images via my server to google bucket, they should be directly uploaded (or downloaded) from the bucket.
(I also don't want to display another Google login to users to grant access to their bucket)
So my best case scenario would be that when user authenticates to my server, my server also generates short lived access token to specific Google storage bucket with read and write access.
I know that service accounts can generate accessTokens but I couldn't find any documentation if it is a good practice top pass these access tokens from server to client app and if it is possible to limit scope of the access token to specific bucket.
I found authorization documentation quite confusing and asking here what would be best practice approach to achieve access to the cloud storage for my case?
I think you are looking for signed urls.
A signed URL is a URL that provides limited permission and time to
make a request. Signed URLs contain authentication information in
their query string, allowing users without credentials to perform
specific actions on a resource.
Here you can see more about them in GCP. Here you have an explanation of how you can adapt them for your program.
I am trying to build mobile app using react-native backed by spring boot apis and in order to implement authentication and authorisation, i researched and found JWT is a way to go.
There are lots of implementation available for example https://medium.com/#maison.moa/using-jwt-json-web-tokens-to-authorize-users-and-protect-api-routes-3e04a1453c3e
I have few questions:
Most of the time you have to store JWT token on your local mobile cache to use this on subsequent requests. How safe is it to store the JWT tokens as it is.
Normally your create user is not JWT protected because without creating a user you can't generate any tokens. So it practically means you have exploit your user creation and it turns hacker can create any arbitrary users and generate the tokens and get access to system how to avoid that.
How to restrict token roles based on only the logged in user. can we bind mobile device id to generate the JWT tokens.?
We are building an application with a React/Redux frontend and a NodeJS/Express Backend. I, not being a security expert, opted to go with Auth0 to handle Authentication.
Auth0 returns an ID Token and an Access Token when a user logs in, this access token is used to authenticate and access our backend API.
We've seen this Access token stored before in Local Storage but Auth0 then contradicts that here. Furthermore, in this answer it seems that some recommend storing in Local Storage, as does this one.
This has me terribly confused. How can we store and persist the token without storing it in memory? We could store it in Redux only but it'll clear on refresh which isn't a solution.
Here they show that the User Signs in and the Access Token is returned and that later it is to be sent along with API Requests, which I understand, but where is it to be stored in the meantime?
How are we supposed to store the access tokens so our application can access our API? Or are we not supposed to store it at all?
We decided to store access tokens in a React Context Provider. Looks like Auth0 has updated their quickstart guide to do the same.
The best way to store AT/RT is by using a distibuted cache memory for your client backend servers. By this way, you make sure that all API calls must transite by your backend application. In your frontend, you pass only the ID_Token witch has to be used to identify your end users.
User sends ID_Token --> Client (backend web app) checks the Id_Token and Get AT from cache memory --> Call the APIs with AT.
I am trying to get an access token using my dropbox username and password.
I don't want to go and generate it from there site, as mentioned in there help documents.
No, Dropbox API apps should use the OAuth app authorization flow to get an access token for the user, so that the app doesn't have to directly handle the user's credentials. You can find more information on this process here:
https://www.dropbox.com/developers/reference/oauthguide
The method of generating it on the App Console that you mentioned only works for the owner of the app, but the OAuth app authorization flow can be used for any account.
Note that while this does require manual user intervention, it generally only needs to be done once per user. Once the app has an access token for a user, it can store and re-use the token for future API calls without further manual user intervention.
Dropbox API access tokens don't expire by themselves, though they can be manually revoked by the user.
I want to use dropbox's Python SDK to authenticate app users with OAuth2.
I would like to store each user's authentication token so that they don't have to authenticate every time when app needs to access a folder in their dropbox. The tokens will all be stored on the server side.
What would be a proper implementation here, especially in terms of user security? Should I store the user tokens in flat files or databases? plain or encrypted?