I am developing mobile apps with Ionic2 for frontend, django rest framework for backend and django oauth2 toolkit for authentication. While the mobile app user submit the email and password server returns the client_id, access_token and refresh_token and save them in local storage of mobile phone. Whenever mobile app user open the app, it request with access token and client id so that they can automatically login the user. And if this procedure fails, it request again with refresh token to get new access token.
My question is that the way I am doing is right for mobile users to not have to login anymore after first time? and also even the mobile app user open the app after long time like for example 1 year, could it be still possible that mobile app user can be logged in without logging in again?
I just want to be sure if there is any limit time of refresh token or some possibilities.. Thanks in advance guys!
If you think that you mobile can access after a year, then you are wrong. Even you can't access it after a certain period of time. And this period should be given by you that, how much time you want to make your token live.
And it's really weird solution to make token for life time.
I think this may help you --
OAuth2 and Google API: Access token expiration time?
Why do access tokens expire?
Related
We are developing a web application in AWS which stores its users in Cognito. As part of this, we are required to have an integration with an existing desktop application, where the administrator of a client can create a read-only user for the website for data sent from the desktop app.
Because of this read-only user requirement, there has to be a user associated with the authentication for each instance of the desktop app installation. This is no problem, as we are happy that all local users of the desktop application have their data logged to the same place in the web application. The tricky part is that we are not able to have the username and password as common knowledge for the end-users of the desktop app.
It has been suggested that we could use token-based access to allow the desktop app to access our API, but these are all time limited and we would not be able to have the user re-authenticate each day. However, another suggestion is to create our own "key" which contains the username and password of the Cognito user in such a way that the application will be able to use it, such as encrypting the username and password with the decryption key available to the desktop app so that it can authenticate as that user itself without the end users having access to the account details.
I would like to know if there is currently any best practice way of handling a requirement like this that is better than what we currently have available.
To summarise:
We have an AWS API with Cognito Authentication
We have a desktop application which needs to access the API
We cannot have users know the details of the account being used to access the API
We need a way to provide a key that will allow the desktop application to authenticate itself against the API in such a way that the token will not need to be refreshed over time
Thanks for any help.
Unfortunately this requirement:
"We need a way to provide a key that will allow the desktop application to authenticate itself against the API in such a way that the token will not need to be refreshed over time"
is not going to be possible with Cognito. Assuming you are using Cognito user pools, the id and access tokens obtained on authentication are only valid for 1 hour, then they have to be refreshed using the refresh token. The refresh token can be configured to be valid for a really long time (years even) so you could setup a flow where:
The app authenticates itself against Cognito once
Gets a refresh token that is valid for a really long time
Throws away the original encrypted username/password
Uses the refresh token to get a new id/access token every hour
You would have to store the refresh token on the client somewhere though. And probably have a support mechanism where this process could be restarted on the client in case the refresh token is lost.
If you are using Cognito user pools, you are going to have to do token refreshes. Same is true if you are using Cognito identity pools - the AWS credentials provided by the identity pool are only valid for 1 hour, then they have to be refreshed.
First of all, i am still new to django rest framework jwt so pls excuse my stupidity if im wrong.
Im wondering about how to create a logout function for jwt as when user want to logout and switch account, they will need this function.
Based on the what i seen in many other logout post,
- there is no need for logout function as the token isnt save on server side so closing and opening will result in having to login again.
- jwt is using expire time for it so it will logout when the token has been expire , provided if the verify token is set to True
But what i want is to have like a remember me function where user will stay login when they close and open again, as one of the suggestion is turn the verify token to false or set expire time to weeks. But then how does the user logout if the token expire time hasnt reach yet ?
As i am using jwt and djoser, the logout function of djoser is for drf only and not for jwt. Since i am also using the api for mobile devices, so the user will stay login whenever they open the app (provided they did the first login) like facebook and many other apps.
Please give me guidance on this. Thank you
Ideally, you should be using JWT in a stateless manner, which means the there is no session(The JWT token has an expiration time and will be invalid after that time, clients need to implement some mechanism to re-authenticate or extend the token). Given that, you don't need a log out at all.
I have to implement a REST backend for mobile applications.
I will have to use Django REST Framework.
Among the features that I need to implement there will be the registration user and login.
Through the mobile application the user can create an account using ONLY the Facebook login.
Then, the application will take the information from Facebook using the token-facebook and it will send this data to my server.
I tried using python_social about Facebook authentication and user registration using the Facebook token.
At this point I have doubts:
think there could be two choices:
1:
The mobile application use the Facebook-login to retrieve user data and will send a request to my server to create a new user with the Facebook data user and passing the Facebook-token.
In this case, in the server side, it will not be integrated python_social and facebook-token is a simple profile field.
Doubts: how can you implement the next login (which password Is necessary to use?)
2:
The second possibility is to use python_social. In this way there are no problems for subsequent logins. The token Facebook will be used to retrieve the data (and validate the user) by calling: do_auth
But in this case, for each user, the server will have to make a request to Facebbok (which actually is possible to avoid: the mobile application has already recovered all the data)
What is the best case? What do you usually use for authentication backend rest with Facebook?
i didn't unerstand the first case, when you are using facebook login it does the authentication and we will register the user with the access token provided by facebook. When ever user log in we are not worried about the password, authentication is not done on our end. so when ever user tries to login it contacts facebook if everything goes good there, it will give you a token with that user can login.
I am posting to my facebook wall through my app using my user.
I gave to the app offline access but still, sometimes the accesstoken changes.
I would like to know if its possible to use Facebook API to get the accesstoken?
Right now, I used the example.php from the facebook sdk to login and took the accesstoken from there.
again, I dont want the application accesstoken. I want to user accesstoken of using the app.
Thanks.
There is App Login section in Authorization paragraph in https://developers.facebook.com/docs/reference/api/ .
Read it. You have to call it if you get invalid access token error in order to refresh the token. However, sometimes the token is invalid due to lack of permissions and not because the token is expired
I'm planning out adding Facebook integration to a web app I'm working on. For the most part, it's proceeding smoothly, but I am confused on the proper way to handle the OAuth token.
The sequence of events presented by Facebook here is:
Ask the user to authorize your application, which sends them to a Facebook window.
This will return an Authorization Code generated by Facebook
You then hit https://graph.facebook.com/oauth/access_token with your Authorization Code, which will give you a time-limited OAuth token.
Using the OAuth token, you can make requests to access the user's Facebook profile.
Facebook's documentation has the following to say about token expiration:
In addition to the access token (the access_token parameter), the response contains the number of seconds until the token expires (the expires parameter). Once the token expires, you will need to re-run the steps above to generate a new code and access_token, although if the user has already authorized your app, they will not be prompted to do so again. If your app needs an access token with an infinite expiry time (perhaps to take actions on the user's behalf after they are not using your app), you can request the offline_access permission.
When they say to re-run the steps above, what steps need to be re-run to get a new OAuth token? What data (Facebook UID, Authorization Code, OAuth token) does it make sense to save to my local database?
I would like to be able to have the user continue to interact with my site, and in response to certain user actions, I would like to be able to prompt to user if they want to post something to their Facebook wall.
The access token is time and session based and is unnecessary data to store and have no use after the user have closed the session.
The facebook uid is the only thing you need to identify the user.
Since the Facebook API sometimes is horrible slow you could store the username aswell.
But for identification, all you need is the uid.
The documentation that facebook provides has been updated since you asked this question. https://developers.facebook.com/docs/authentication/.