I have developed an express app that's purpose is to send emails. I authorized an email sender using googles oauth2 playground, and their google api. I wanted to use this strategy rather than working with a third party email sender to not be subject to vendor lock-in. I had the system working successfully, but after a day it stopped working with "invalid-grant". In production, I'd like to have a permanent email address (under their google workspace) that is solely dedicated to these bot emails. The oauthplayground says you can avoid the 24 hour expiration, but I recall doing that before and it eventually came up with invalid grant. Is there a better way to set up a bot like this? Or should I just try the oauth playground and using the config panel to avoid the refresh token expiration again?
To start with let me say that invalid-grant means that your refresh token is no longer valid. It is no longer valid because googles oauth2 playground is intended for use for testing purposes only.
Access tokens will expire in less than an hour and refresh tokens created using it will expire in 24 hours.
While it is possible to configure it to uses your personal client id and client secret it is still not the optimal way to go
Even using this method for production is not going to work well for you. If your app is still in testing phase then your refresh token is goin to expire in seven days. You will need to set your app to production in order to have a refresh token that does not expire.
The issue then becomes that in order to use the gmail api your going to need to have your application verified. You can not verify your application using the googles oauth2 playground as a redirect uri as you can not verify that you own this domain.
The solution to your problem is to create an application of your own hosted on your domain. This will allow you to create the credentials you need and have your app verified by google.
under their google workspace
You made one comment that is not clear. If you are using google workspace then why not just set up a service account with domain wide delegation to the user on the domain. You will avoid all the issues you are having above.
Related
I'm working today on a partner environment related to Google Home.
Concretely, when I use google home to give orders on devices, Google calls my API to execute them (as it does with Philips Hue, Netatmo etc ...).
My problem is this: I use keycloak for OAuth management. the Google console has been configured to use it and it works. However my refresh_token expire and this forces the user to delete the linked account and then postpone it.
My question is this: Does Google expect to get an infinite refresh_token after giving its authorization_code? Or I missed something, because Google does not seem to restart the normal connection procedure.
Keycloak 3.2, Google homegraph action-on-google
Typically, yes, Google assumes the refresh_token has either no expiration or an extremely long expiration period. But it does acknowledge that the refresh_token can either expire or be revoked. In that case, you need to make sure your OAuth server returns HTTP code 400 with the OAuth error invalid_grant.
I personnaly consider a good practice to revoke refresh tokens after an period of inactivity.
This gives a pretty good user experience while keeping the database updated.
After reading the documents of Google API. I know that if a project we create needs to access private data, we should use oauth. But here is my situation. we will open a business account in Youtube, and we will create a project to push videos to our own account, we don't need to operate other user's' account. Can we use google youtube data api without OAuth?
There are two ways to access private user data with Google APIs.
Strait Oauth2. where you have a consent for asking the owner of the account if you can access it
Service accounts which are technically pre authorized by the developer.
Normally I would say because you are only accessing the one account that you own, use a service account. Unfortunately the YouTube API does not support service account authentication.
Due to the lack of service account support you will have to use Oauth2. I have done this in the past.
Authentication your script once, using a server sided language of some kind. The Authentication server will return to you a Refresh token. Refresh tokens can be used at any time to get a new access token. Access tokens are used to access Google APIs and are only valid for an hour. Save this refresh token someplace. You will then be able to allow access the YouTube account in question when ever you like.
Note: You will have to watch it. Refresh tokens can on rare occasion become invalid. I recommend having a script ready that will allow you to re authenticate the application again storing a new refresh token. Its rare that it happens but it can happen best to be pre-paired.
Oauth Play ground
Part of the point of Oauth is that it identifies your application to Google though the creation of your project on Google developer console. Things like quota and access to which APIs is controlled though that. If you spam the API they will know and shut you down. (never seen this happen)
When you request access of a user it pops up with the name of the project on google developer console. This is identified by the client id and client secrete for that project on google developer console. When I use oauth playground I get asked 'Google OAuth 2.0 Playground would like to ..'
So by using playground you are using Googles client id and client secrete to create a refresh token for yourself. If N other devs are also doing this the quota for YouTube may be used up in the course of a day. Also security wise you are now giving that project access to your data. Ignore that for a second what if google suddenly decides to remove change the client id or generate a new one. Your refresh token will no longer work. What if random dev X is using it as well and he starts spamming everything and the client id gets shut down (Think this happened last year) your going to have to wait for google to upload a new client id for the one that has now been banned.
Google OAuth 2.0 Playground might seam nice but its not for daily use IMO its good for testing nothing more. Create your own project and get your own access its not hard just requires a programing language that can handle a http Post.
My tutorial Google 3 legged oauth2 flow
I am implementing an App Store for my application where third-party developers can build there own apps based on my API. I have everything working and understand the concepts of OAuth 2.0, but I don't see how an external app can have timeless access with an access code that expires after one hour. Now you can use a refresh token to request a new one, but that one expires after some time too.
So how can an external app continuously connect to my API when the user of that app allows it only once?
My authorization codes expire after 10 minutes, the access tokens after 1 hour and the refresh tokens after 2 weeks.
I don't see how the app can retrieve data after those periods of time without the user re-allowing/re-installing the application through oauth.
How are bigger companies like Facebook etc. approaching this? Do they have an access token that never expires?
Expanding on my comment, the general recommendation when using bearer tokens is that their lifetime should be reduced in order to mitigate the impact of an access token being compromised.
On the other hand, asking the user credentials every hour or so would be an UX nightmare so OAuth 2.0 has the notion of refresh tokens which will normally have a longer lifetime allowing the application to request a new access token without requiring user intervention.
I'm unfamiliar with the implementation details around Facebook persistent tokens so I won't comment on that, but they are most likely safe. However, you're not Facebook, so my recommendation would be for you to follow public standards like OAuth 2.0/OpenID Connect instead of trying to provide a customized approach.
Regarding your comment about refresh tokens that never expire, it's an acceptable solution, but their lifetime is just one part of the equation. You should consider if they are multi-use or single-use, they can only be used by the client application that they were issued to, they should not be used by browser-based applications due to the difficulties of ensuring secure storage, etc.
OK. So i need some guidance as I am a total iOS authentication noob.
I have a simple app. Users can login to the app, and send messages to friends. There is a web server and a MySql Database that holds the users and login information.
Question: How do I authenticate a user when he logs in safely and securely?
I have spent the last several hours hurting my brain on the following authentication stuff i found from google:
OAuth 1.0 - is said to be good. But it is a protocol and not a library. Do i have to implement this from scratch? Is this even needed in my case for authentication?
OAuth 2.0 - it seems that some sites are using this. I have the same questions for this as version 1.0. I also saw this this message from the library's lead creator literally saying f*** version 2.0 because it was bad for security. But yet so many still use it. Is it dangerous?
The creator of 2.0 has now gone on to make a completely other library because of how bad 2.0 was and because of how unscalable 1.0 was. His library is called OZ. Should I be using this for my server?
I see AlamoFire/ AFNetworking have basic authentication shown in their documentation. Should i just screw the oAuth stuff and just use theirs?
Being new to the authentication thing, all this is very confusing to me. Can anyone knowledgeable in this provide some guidance?
I am currently in the process of creating a cross-platform application and have spent quite some time researching this!
My approach to the project is using a ASP.NET Web API using OWIN middleware.
This uses bearer tokens to authenticate the user.
Using Microsoft.Identity you can limit endpoints down to roles or even individual users (Autherization)
Currently I create a user on the REST API, They log-in at the /token endpoint and then receive a token. This token is then saved to the Apple key chain and can be used to authenticate the user for further requests to the API.
As long as you use SSL this is a secure method and is used widely in many applications.
This approach uses OAuth2 also, so you'll be albe to easily integrate Facebook/Google/etc integration.
Here is a link to the Microsoft Documentation for some further reading on how I did it:
http://www.asp.net/web-api/overview/security/authentication-and-authorization-in-aspnet-web-api
Currently this is working perfectly for me for an angular front-end but would work exactly the same in iOS except you may want to save the token to the KeyChain Storage.
We mostly use OAuth 2 creating custom system on iOS to handle the authentication.
Nothing is ever bullet-proof but the 2 token system decreases the chance for stealing credential quite nicely.
The AlamoFire, AFNetworking or any other libraries you amy find have nothing to do with this though. What type of credentials you use depends on your choice or rather the choice of the API. You may use these tools to ease your communication with the API though.
So what the idea behind this is you will try to send your user name and password only once when logging in and then you will receive the two tokens which are further used to communicate. This will decrease a chance for someone to intercept the request with the user name and password which are the ultimate key to get the access to the user data.
Next is "refresh token" which is used to receive a new "access token". This call should be made every few hours or so (controlled by the API). If someone was to steal this token he would be able to use it to get further access for an infinite duration or until the owner chooses to invalidate the refresh tokens (this is what happens when you click "log out from all devices"). So this is still quite bad if someone gets it.
Then there is the "access token" which is used for each and every further request to the server. These tokens have a limited time till they are invalidated so if someone was to intercept it somehow he would have the access to the data for the duration of the token.
So assuming this is the procedure that is done on the backend this is what you need to do:
If you have the access token and is valid simply use the service
If you receive the error that the access token is invalid you need to refresh the access token using your refresh token
If refresh token reports an error you need to navigate back to the login screen
If the app has no refresh token then simply go to the login screen
There are some other things that are nice to cover such as if the request reports an invalid token you should pend the request, refresh the token and then repeat the call to the pending request. A system around this may be quite large.
This is pretty much it about the tokens and authentication but there are other parts of the communication which increase the security such as using a https secure connection. When talking about security you must take a look into every part of the communication.
Goal
Fetch a company's updates save them locally in a background task
Problem
This should be done as a backend service without any real user interaction. We could provide a user account to use, but the authentication is a problem: There is literally no one to answer the OAuth redirect and there is no public redirect URL to configure, since it's a background service.
Is there any way to access the API without having a redirect URL or a real user?
You can get an initial access token in a regular front end flow, for you as the app developer i.e yourself as the LinkedIn user. Once you've got that, you can store it in the backend and use it for 60 days to get access to the LinkedIn APIs.
After 60 days you need to refresh the token as documented in:
https://developer.linkedin.com/documents/handling-errors-invalid-tokens
Unfortunately LinkedIn does not (yet) support an autonomous refresh flow where your app can get a new access token by presenting a refresh token on a backchannel. So the developer will have to refresh the access token by a manual login every 2 months.
Well, it is still all HTTP and HTML, so in fact there is no real reason to show the OAuth dialog to a user, as long you can strip out the necessary parts in the HTML authentication dialog and send a valid response back to the server, using the username and password from the user (which you can obtain from him, or save it yourself in a config file if it is you).
Note that there might be a legal issue if LinkedIn demands you to actually show the dialog, beside that, there is no technical need.