I'm making calls to a Web API using a xamarin mobile app and I was wondering when receiving my authorization bearer token could I not simply store it in the xamarin.auth account store along with the user's credentials? I figured this would be a better place than say a global variable in the app. Looking for feedback and any better options. Thanks!
In my opinion there is nothing wrong with using the account store for storing an access token (using the account properties dictionary). I did it myself on one app where I didn't have any other data to persist, so didn't have a custom data access layer.
Access tokens should not be stored. Refresh tokens are OK, but Access not.
From security point of view.
Related
I'm writing a web application that reads my personal calendar data, crunches stats, and then spits them out for the world to see. I don't need an authorization flow. Is it possible to leverage the Google APIs without going through a user sign-in flow? In other words, I want my personal Google account permanently and securely signed in to my server without the risk of my token invalidating or having to re-auth.
Right now I'm signing myself in with an offline token, then uploading the authorization file onto my server, basically spoofing the server that I already auth'd. Is there not a cleaner way?
I've spent hours reading through the API docs and Auth docs, but haven't found and answer. If there is a page I've missed, please point me to it!
PS. I'm using the Calendars API through Python/Flask on Heroku, but that shouldn't matter.
An alternative approach is using a service account while sharing your calendar with that service account. See https://developers.google.com/accounts/docs/OAuth2ServiceAccount
So, you want to be remembered.
If you want to dispose of any kind of authenticacion but yet the user needs to be recognized you should be using a cookie.
On the server side that cookie should be used to select the offline token.
Of course, without that cookie the user needs to be authenticated in any way. I would make them reauth by Google so you get a new offline token.
Hope that it helps.
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 would like to access my own facebook news feeds using spring social facebook. I have registered my app and i could able to get app key and secret key. How to generate facebook access token for given app key and secret key using spring social facebook(programmatically)?
Now i'm using the link https://developers.facebook.com/tools/explorer generate the temporary access token which is valid only for 60 minutes.
How to generate the access token in my java application itself without having any login page redirecting to facebook redirecting back, etc.
If you're wanting to use the token to access user-owned resources at Facebook (e.g., the user's timeline, friends, etc) there's no way to get a token without involving the user. That's on purpose so that you aren't allowed to fetch data or write data to Facebook without getting the user's permission to do so.
But if that's what you want, then you must redirect the user to Facebook and back. This is OAuth 2's authorization code grant. Spring Social's ConnectController can help you with this.
You might be able to do it via the JS API, but it's been awhile since I've done it that way and I know a few things have changed at Facebook in that regard. And it probably relies on OAuth 2 Implicit Grant (which involves a redirect).
There is another way to obtain an access token without redirecting: Via OAuth 2's client credentials grant. But I don't think that's what you want. Such a token can only be used to work with non-user resources (such as Facebook's Insights API). But if that's what you want, then you can use OAuth2Template's authenticateClient() method.
Again, to be perfectly clear, it is very much by design that you can't obtain a user access token without involving the user. And with Facebook, that will require redirects.
Can I access my SkyDrive using a permanent access token?
Basically, I want to grant a particular app (my own) permanent access to my personal SkyDrive account. Possible?
My use case: I'm storing some content on my personal SkyDrive, and I want to access that through my C# web app, but I don't want to have to authenticate on the client every time.
Asking around on the SkyDrive API forums, it sounds like this isn't possible.
What is possible, however, is authenticate once using OAuth, then use the refresh token passed back in the initial authentication to refresh the authentication.
Browsing though the Foursquare API documentation, I noticed that when obtaining an access token with ajax there is no need for a secret key (for obvious reasons). But this makes me wonder what is even the point of having to register apps with foursquare in the first place if you can just fake being any app by using their client key. Why do they allow this?
https://developer.foursquare.com/docs/oauth.html
Your answer is in the document you referred to
Since each credential is tied to a particular URL
The point is Foursquare is looking at the URL of the requesting script for security. If there is no registration there is no URL to tie the credentials to.