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.
Related
Im trying to find some best practices on how to solve my problem.
I have a microservice application with oauth2 and firebase for authentication and authorization.
Our application needs to connect to a 3rd party rest api which is secured with oauth2 as well.
Is it possible to integrate both implementations or do i need to make my own solution?
One of my co-workers implemented the authorization-code flow needed to access the api and we basicly store access and refresh_tokens in the database to access this 3rd party api. But it doesn't feel right, i cant find any best practices either, can anyone help me out?
What your co-worker implemented is pretty typical: separating out the authentication and authorization for your own application (which you manage with Firebase) from your users authorizing your use of the 3rd party API.
Here are some best practices you should be following when implementing your OAuth flow:
Use the state parameter to avoid CSRF attacks. Store it in your database and compare the callback state with the one that you randomly generated for the user
Encrypt access and refresh tokens. Refresh tokens in particular provide long-lived access
Verify that the scope you asked for is the scope that was returned: some providers allow users to adjust the permissions, which can lead to unexpected errors
Make sure your refresh tokens don't expire. Check with the provider's docs to see how refresh tokens are deauthorized. Some are time-based, some are based on new refresh tokens being issued, but in any case, make sure your refresh token stays valid, as if it is not, you must get the user to re-authorize your application
You can also use a managed OAuth provider to abstract away all these elements. Xkit, which I work on, integrates with Firebase Authentication so your users can authorize your app, and you can retrieve each user's tokens with one API call.
My current application access one of the Google APIs using "3-legs" OAuth 2.0. User authorizes the app on Google consent screen, then the app requests API on behalf of the user and shows him some fancy data loaded from API. Everyday my application loads and transforms data from this API, so when the user comes next time, he sees the most relevant and actual data.
Everything works fine on the start, but as time goes, I faced two problems:
1. Query limits.
2. Token lifetime.
My question is dedicated to the second one, that I refer as "token lifetime". After some amount of time, the access token expires, and when user comes back to the app, our app obliged to send him to consent screen again. Moreover, all the time while access token has been in expired state, my app cannot load relevant data for user.
How can I solve this problem? How to continue lifetime of access/refresh tokens? Would Service account help? Would Service account work for Google Search Console API for every user, or should the user be a G Suite user inside my domain or what?
These questions are completely unclear from the official documentation here and from the Search Console API documentation.
If you have past experience with Google's APIs, please help me!
Thank you
When you use OAuth with user-consent, you do not need to prompt the user for consent repeatedly.
[a] If your usecase is entirely online and you want to be able to request a token each time the user visits your app, use the Google Sign In library or see this documentation for client-side apps.
[b] If your usecase is that you want to be able to obtain access tokens even when the user is not present, then you need to request an authorization code and store your refresh token. Your refresh tokens are longer-lived tokens and can be exchanged periodically for access tokens.
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'm working with 3 Google API Services(Analytics, Webmasters, PageSpeed). I have a single Google API client ID(with all 3 services activated) and common Google API PHP SDK in my server.
User of this aplication should be able to grant and revoke access for each service independently at any point of time depending on his usage. Is this possible?
Testcase:
If user wants to use only analytics service initially, he should be able to grant access for only analytics and later if he wants to use pagespeed service also, he should be able to grant for pagespeed also without compromising access for analytics. If he wants to use analytics & webmasters later, he should be able to revoke only pagespeed access without compromising the access for analytics or webmasters.
When you request an access token, you specify the resources you want access to. If later you need to access another resource, you request another token for that resource.
You can simplify your implementation by setting the include_granted_scopes to true when requesting the token. This will include all previous authorizations so you only need to deal with the new token.
AFAIK there's no way to revoke access to specific scopes, even though the documentation mentions that "When you revoke a token which represents a combined authorization, all of the authorizations are revoked simultaneously;". This actually happens even when revoking individual tokens. Also, the Google account user interface does not allow the user to specify which permissions he wants to keep, it's only possible to revoke all access from an application.
See the docs for incremental authorization.
I'm a little new to this and please bear with me if I ask dumb questions.
As what I know, session is something saved at server (either in file or in database), and client access it via sessionid saved in cookie. To keep user login information, we can simply put a 'logged_in' column and an 'expired' column in session file or session table.
As far as I know, Oauth2.0 is designed for third party client to access the server. The whole process is controlled by an access_token, which is quite similar to sessionid (at least from my knowledge).
So, here's my question, is it possible to use Oauth2.0 to completely replace session? I.e., even people are using the website designed by me (NOT third party website) to access my own server? So that I have a unified authorization framework for user accesses both from my own website and any thrid party website.
Is there any pros&cons of using session & oauth 2.0?
Lastly, how about mobile app? I know for third party mobile app, they normally use oauth to access the server (many websites provides oauth api). How about if I am going to write my own app for my own server (NOT third party)? Does Oauth 2.0 apply here too?
To summarize, my question is actually is, is Oauth 2.0 universal that can be used in all kinds of user authorization control situations from all kinds of devices?
Thank you very much.
Though both are short-living entities, session IDs and OAuth tokens are fundamentally different and used for distinct scenarios. A session is used to identify a user of a web application, thus related to the end user. An OAuth token is used to grant access to a third-party service to access a limited set of protected user resources (e.g. read user contact information or send a mail from the user account). Though the token refers to the granter (i.e. end user authorized the grant), the token related more to the third-party application.
To give you an analogous example: imagine that you have a safe at your bank (i.e. your protected resource). The session is your id for the bank: give it to someone else and he will be you, he can get everything from your safe. On the other hand, a token is a limited authorization to someone else to your safe: e.g. your approval that he can get 10$ from your safe while a security guard is watching.
As a summary, sessions and tokens are not interchangable.