I'm sure thousands have already asked it, and I searched it for at least 2 weeks, but couldn't find a simple answer.
I have a mobile app where I have a login system so the process is very simple:
user logs in with email, password
server checks data and returns OK and a user token
now each request of the user will be with the token attached
server gets a request with token, checks if it is valid for a user and continues.
Now my problem is how do I store the token:
I want to have several tokens for same user (logs from iphone, ipad...)
until when this tokens exist? when do I delete them?
Any ideas on what are the best practices?
OH ，I'm also looking for it, and I just know the token could be stored with Redis/Memcache on Server Side.
Related
I'm currently working out a concept for an (REST)-API / Backend for an App, completly theoretical at the moment.
Since I have never done that before, I'm pretty unsure if things work like I think they do.
So I want to have an Login, where user send their username and password to the server and get an authentication-token, which will be used for future requests. (I think this should be correct to this point)
Now for what I don't know how it exaclty works:
When the client has a authentication token and makes a request to get something for the specific, logged in user, do I have to submit some kind of ID linked to the profile of this user in each request?
Or can the server find the correct user and accordingly the corresponding data for the response depending on the authentication token?
I'm working on an application where an administrator will send a unique link to a user for them to fill out a form. The system requires authentication in order to fill out a form, however I would like this unique link to "skip" the login step for the user. ie when the user receives the link, they can simply click it and fill out the form without logging in, but behind the scenes the user is actually authenticated with a Json Web token. Ideally I would like the link to never expire, or possibly after 1 year so the user could use the link 6 months down the road and the link will seamlessly still work for the user.
The most obvious solution would be to generate a JWT token with a lengthy expiry when the admin generates the link and just include the token in the url that is sent to the user. When the user receives the link, they already have a JWT token so they don't need to login. However this feels like it may be insecure because now the user has a JWT token for their user with a long expiry sitting in their email inbox.
I think I might be able to include information in the JWT token that would restrict it for that specific purpose (filling out the form), but I'm not even sure if I'm on the right path here.
What is the best way to do this, is there any other recommended ways to create sort of a "pre-signed" url that skips the login step?
I'm using ASP.NET Core as the backend, but I'm not sure if it's relevant as this is more of a general authentication / JWT problem.
doesn't matter what precautions you take, anyone who gets a hold of the email would be authenticated. I would consider PGP (or the like) in sending email to user.
I am making an app where I need to have the user log in into their spotify account.
I would like to know how can I know if the user is already logged in or not into Spotify?
What I am trying to do in my application is ask to log in only if I have never logged in before and take the user through the authentication process.
If I have logged in before I want to skip the part where I ask the user to log in. This would have to work also if the user has logged in, left the app for some time and came back to it, I don't want to have to require a re-login by the user. How can I get that status from Spotify ?
I appreciate any guidance with this, thank you.
Since it's very likely that the access token has expired by the time you want to use it again, you would need to use the Authorization Code flow, storing the access token and refresh token of the user.
You can try making a request to an endpoint like Get Current User's Profile passing your current access token.
Should it fails, try refreshing it. If you get an access token back, then you know the user is logged in and you have a valid token you can use. Otherwise, consider the user is not logged in.
Where to store the refresh_token and access_token is up to you. You could do it in localStorage, or even better, in a database.
I am planning to develop something small in windows 8 using HTML/JavaScript project type. I have very basic question. How will i manage the session that who is logged in and what they are doing? This looks kind of absurd question so i will try to give some details of what i have in mind.
User opens the app and gets login page.
User enters username/password.
App calls WCF service or WebAPI and validates the user.
After the third step, user information has to be kept somewhere because i have to know every time who is the logged-in user so that i can check on every operation that what rights the user has and is he authorized to execute particular operation or not.
Since everything here is HTML/JS, i dont know where should i keep the user login information?
Can someone please throw some light as what am i missing here?
Use PasswordVault API to store the password or other secret
http://msdn.microsoft.com/en-us/library/windows/apps/windows.security.credentials.passwordvault.aspx
Then you can send your auth token with the subsequent request.
Is this what you are asking? Or, I misunderstood it?
The long QUEST to get an access token
app gets a request token from twitter
user clicks a button on the ap
app opens a twitter page, user types username/password
twitter gives user a PIN
user use this PIN in the application
GREAT, finally app exchange the request token for an access token
Questions:
This token belongs to who? I mean, i don't even know his username!
The user will have to repeat the steps above every time?
I can't figure out how to fit this into a real application.
Thanks in advance.
Once you have the token, you can call the account/verify_credentials endpoint, which will return you the User profile that the token belongs to (also confirming everything works as intended).
You can then associate the twitter account and the tokens and store the token locally. (They are good forever unless the user later revokes access for your app). How you manage stored tokens depends on your app platform, your needs, etc.