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.
Related
Basically,
I have SPA app with JWT authentication. Now my question is, there is a page that has follow button, so on the first load of page, I need to know if user is logged in or not, so I can disable/enable button.
Approach 1: Before page load send access token and if it is successful render like user is logged in, if it fails render like user is logged out
Approach 2: When user is logged in, keep that state in LocalStorage and just check local storage and render page from that
Is it correct to just keep state of logged in user in LocalStorage? I think that is where you should store ID token (if you use them) that only has user profile information?
Of course I will check access token on each request and from response I can change state in LocalStorage. Problem is that on initial load of page, should I check access token server-side before rendering?
If I keep state in LocalStorage than that user will be logged in on that device basically indefinitely, until he clicks "log out" or tokens fail?
Can anybody see potential problems with keeping state in LocalStorage?
It's OK to keep this information in the local storage. I mean, you can keep a variable there, that will just tell you "this user is logged in as userX". You can then safely utilize this information to display information on your page (e.g. Hi userX!). Even if someone manages to steal that information, it doesn't give them much information.
As you said, you will have to check the credentials on every request anyway (access token, session cookie, etc.), so it's not an issue to have this non-sensitive data in the local storage.
You can of course go with approach 1, but in my opinion, it's just adding unnecessary traffic.
If it bugs you that it will seem that the user is logged in for ever, then you can also persist some TTL in the local storage, and after that TTL treat the user as logged out.
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.
I'm trying to make a check for a specific user logging into Instagram and approving an app I've created. Is this possible?
Example flow :
User comes to my app
User clicks login/authenticate via Instagram
User logs in (or check is made if user is logged in via Instagram)
User is redirected to my app's callback URI.
When the user gets back to my app I would like to be able to check which user has authenticated - is this possible? At present I'm only able to get an access token.
Thanks for any help.
I've actually solved this by using the server-side flow mentioned in the API documentation (http://instagram.com/developer/authentication/) which gives me back a response including the details of the user logged in if following the extra step (code->access_code application, etc).
I also figured out what you mention above too, so both ways are good.
Thanks for you help.
The information is not directly returned to you in the OAuth process, but once you have the access token you can load user information using the https://api.instagram.com/v1/users/self/?access_token=XXXX endpoint. That will give you data about the currently logged in user (including ID and username)
In the Facebook's Graph API, once we have initially authenticated the user, we can interact directly with the API (from the server) to obtain a long-lived page access token. This long-lived page access token never expires. (https://developers.facebook.com/docs/facebook-login/access-tokens/)
In reading LinkedIn's documentation, it appears that it is impossible to obtain an access token with an indefinite (non-expiring) access token. It seems that they expire every 60 days. However, these access tokens can be refreshed before the 60 days is up.
What isn't entirely clear from the documentation is whether or not the access token renewal can be performed on the server alone without the client's interaction. The language of the documentation suggests that the interaction of the client (browser) is required, but nothing is explicitly stated.
So, my question is, is it possible to renew a LinkedIn access token using the server alone, without the interaction of the client (browser)?
Relevant LinkedIn reference material: https://developer.linkedin.com/documents/handling-errors-invalid-tokens
As it turns out, the access tokens of linkedin can not be refreshed without having linkedin user logging in to linkedin. Please refer to the first comment here by LinkedIn employee which clearly states a note that "this refresh will only work if the user is still logged into LinkedIn (authenticated) and the current access token isn't expired. Otherwise, the user will be presented with the login dialog again."
I guess that is now a major issue for those who were previously storing the linkedin access tokens to database for later use.
I am mentioning few links here which refer to the issue with refreshing linkedin oauth2 tokens (hope this makes it clear for everyone who is struggling with the same issue):
1) This refresh will only work if the user is still logged into LinkedIn (authenticated) and the
current access token isn't expired. Otherwise, the user will be presented with the login
dialog again.
2) There is no way to refresh the token using the old authentication token/secret. User
needs to log into linkedin in order for you to refresh the tokens. We use this flow as it
protects our members and their data in the best possible manner.
3) Refreshing an access token is very simple and can happen without an authorization
dialog appearing for the user. In other words, it's a seamless process that doesn't affect
your application's user experience. Simply have your application go through the
authorization flow in order to fetch a new access token with an additional 60 day life span. When the following conditions exist:
-User is still logged into Linkedin.com
-The current access token isn't expired (within the 60 life span)
We will automatically redirect the user back to your redirect_uri without requiring them to reauthorize your application. If they don't exist, we'll prompt them to login and then redirect
them.
4) We have also standardized the duration of the authorization tokens. Previously, members
could choose to grant tokens that were as short as one day or as long as forever. Now all
tokens are 60 days in length, with the ability for you to extend them in a series of rolling 60 day increments whenever the member comes back to your application. To prevent a bad user experience in your application, be sure to proactively refresh tokens and elegantly route any expired tokens through a refresh flow.
5) As long as the user is logged into LinkedIn and their current access token hasn't expired, you can fetch an access token with a 60 day lifespan the next time the user comes to your application.
I had the same question and the LinkedIn docs and forum posts are confusing, but I'm pretty sure now that it's not possible to do it programmatically without user intervention (i.e. the user needs to login to your app via LinkedIn auth to refresh the token).
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?