I am using Gmail API to retrieve recent messages. And of course Gmail API requires OAuth2 Token to authenticate the requests. And repeat the task indefinitely every nth time.
However, I think that this is an impossible task. Because OAuth token expires. Though it has a refresh token, It will still need initial user intervention to start the task.
Does anyone experience the same problem? If so, how did you guys overcome it?
I'm kinda stuck on this matter. and would love to hear a solution.
I am using Gmail API to retrieve recent messages.
Your trying to access private user data you need the consent of the user to do that.
this is an impossible task. Because OAuth token expires.
Tokens expire this is intentional if they didn't and someone got your token they could use it for ever by having an expiration time on the token this limits how long a hacker would have access to your data.
Does anyone experience the same problem? If so, how did you guys overcome it?
These are things you should not be trying to over come these are things you should accept and try to understand the security they bring to your application.
I'm kinda stuck on this matter. and would love to hear a solution.
If this is a google workspace domain account, you could consider using a service account.
However if this is a standard google gmail user then you will need to use Oauth2 and request the consent of the user. If you have a refresh token you should not be having an issue you just need to authorize the user once and you will be able to request a new access token when ever you need.
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.
I am using Authorisation Code Flow in my web application. I would like to get a refresh token for the web app itself but also an offline token that I will save in the database so I can use it later on for an offline task.
However I am struggling with that. I cannot use grant-type password because I don’t want to ask the user again to enter his/her credentials and also authorisation code is only one-time use so I cannot integrate it with the current flow.
Is there any other way to generate an offline token from a different token? I have tried using grant type refresh-token with scope offline_access but that didn’t work.
After keep working with Keycloak for several months, the answer is simple: it is not possible.
Offline token is effectively a refresh token with no expiration time so you can get one or the other but never both as part of the same request/response.
From a user point of view, we created a new page to request this token using password grant-type and offline scope. User need to re-enter his password but it seems ok from a security point of view. This approach works for us given the requirements to get this token as it is an unusual task.
You can also generate offline tokens using service account, check keycloak documentation on service account.
Following discussion will help you to understand different scenarios generating and using offline tokens
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.
I am trying to figure out how an access token in OAuth 2.0 should be used. To be more precise, I am trying to use the Google Plus API from a web application.
I am now able to get a code and from it an access token. The problem is that this token is only about 3600 seconds valid.
Is there a way to get another token without making the user go again through this process: https://developers.google.com/accounts/images/consent1.png because it seems a bit irritating. I know of the offline access and its refresh token, but it doesn't feel right to have permanent access to a user's account.
Do you have any ideas on how should I proceed?
I'm definitely not an authority, but I believe the answer is 'no'. The offline token allows you access without subsequent user approval, but only to the scopes to which the user already agreed when authenticating for the first time. Also, the user has the option of revoking your application's access at any time, which when combined with their previous consent means they both a.) know what they're allowing; and b.) can stop it at any time. Ostensibly, if a user uses your app enough that they constantly have to get a new token, they already trust it to act on their behalf within the scope you set, and the offline token is a way for you to take your relationship to the next level :)
I realize this is probably more philosophical than you were looking for, so apologies if it isn't pertinent to your situation.
I have a client who's requesting using oauth on their site so users can authenticate using their facebook or google credentials. I was wondering what information during the process is persistant so I can link them to their account records in my database.
My first instinct was to use the final token (the one used to actually request information from whatever site) but from my understanding those tokens can expire thus breaking my link. How can I identify who is who if their token expires?
If you're still unsure of what I mean, take stackoverflow as an example. I login to stackoverflow using my google credentials. How does stackoverflow associate my oauth login to my account information? Somethings has to persist.
I feel like I'm missing something glaringly obvious, but for some reason I can't connect the dots. Most likely due to my ignorance regarding oauth.
Any insight would be greatly appreciated.
EDIT: I just realized stackoverflow uses openID. Am I barking up the wrong tree? Can this be accomplished with oAuth?
It depends on what you're trying to accomplish. If the client wants to be able to manipulate the user's data on Facebook from their site then something like OAuth is going to be necessary.
If the client just wants to keep their user's from needing to create another user name and password then OpenID is probably the way to go.
If you use OAuth, when the token expires you have to go through the login process again and ask for another one. The timeout is a valuable security feature.