I want to revoke the session of a user logged in to my app with google authentication.
I retrieved the informations for this user available on this image. Among them we find his token, useful for the revoke.
According to the documentation provided by Google there is a REST call to answer my problem.
https://developers.google.com/identity/protocols/oauth2/web-server#tokenrevoke
However I get this error every time :
The requested URL /revoke?token=eyJhbGciOiJSUzI1NiIsImt..........
was not found on this server. That’s all we know.
Maybe the token which is not valid but I don't understand why in this case.
I think we need to start with being clear as to what it is you are trying to do.
If you are trying to log the user out of their google account the anwser is you cant. Google does not allow third party apps to log users out of their accoutns.
If you are trying to log the user just out of your app itself. Then assuming you have a web app just delete the session or the cookie depending upon how your system is running.
If it is an installed app again just delete the stored tokens which you either have stored in a var you are passing around or in your database.
If you want to completely have the users consent to your using their Google data removed then you would use the revoke command. Revoke world require that you send a valid access token. This will remove all consent that the user has granted your application to access their data. Revoke is not preformed on an Id token.
However by looking at your image I can see that you have an id token, which implies to me that you are using Google signin which is not Oauth2. Revoke is intended for use with Oauth2. Try sending the one that say authToken that might work. If not I think you should just remove the session cookies.
POST request works, GET request return the known error
Related
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
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.
I am trying to support "Hybrid" Federated Login and oAuth2 (using logic from this document) for a webservice which will:
support Sign in using your Google account on my site. That is, from the documentation: You can also choose to use Google's authentication system as a way to outsource user authentication for your application. This can remove the need to create, maintain, and secure a username and password store.
Access the user's Google Analytics.
Here are the steps I have done.
I form my request to https://accounts.google.com/o/oauth2/auth with the scopes (Google Analytics) I want access to.
I Get redirected to google where it has my icon and which scopes I am requesting access to. I grant access.
I get redirected back to the callback page.
I get the tokens (access and refresh), as well as a huge id_token string (which I don't know) and store all of this information in my database.
I then make a call to https://www.googleapis.com/oauth2/v1/userinfo?access_token=xxxyyyzzz to get the user's email and name and store this information in my database too. I also notice it returns a id field which to my knowledge never changes and I presume is some sort of unique identifier. I store this too.
Question: If I go to Authorized Access to your Google Account section in my Google account, it shows that my site has access to "Google Analytics. BUT, it does not say Sign in using your Google account. This is what I am trying to accomplish. I would have thought using the logic would enable Sign in using your Google account. What am I doing wrong? And what would be the applicable call to google so that users can sign in to my site?
If your site has access to something like your Contacts or Analytics using OAuth, you'll never see "Sign in using your Google account". I'm pretty sure that's only if you use OpenID (not OAuth) only for sign-in.
Specifically, OAuth is used for giving you access to APIs to create/update/delete data, while OpenID is for signing in.
If you are asking how to identify user for future logins, you have two options:
Mix OAuth with OpenID, that is called Hybrid. I have described it on this answer.
Use userinfo scope and request userinfo (email, etc.) after successful OAuth authorization. It is described on Google OAuth 2 documentation.
If you mean automatically login to your web site in future visits you can use OpenID "immediate mode" (openid.mode parameter).
When the user is redirected back, you call the second request from your own (server-side?) code, and get their email address. When you successfully get it, that means that the user is logged on. You can add it to the session (e.g. as cookie), and as long as you have it, the user is logged on. You make the user log out by forgetting the email address, so by clearing the session/cookies.
Add this paramter to the https://accounts.google.com/o/oauth2/auth URL call: approval_prompt=force and then the Sign in using your Google account will always show regardless of whether the user was already signed into that or any other account.
So the call would be like this https://accounts.google.com/o/oauth2/auth?client_id=<client id>&redirect_uri=<uri>&scope=<scope>&access_type=<online or offline>&response_type=code&approval_prompt=force
Goal:
Allow a user to authentication with Facebook into an iOS application which requires access to a protected web service that I'm running.
Assumptions:
There is a native authentication (and registration) system in place for those users that opt not to use Facebook for sign in.
Details:
Assume we want to offer the option for a user to sign in with Facebook without creating a separate account/credential for our system.
Because we support our own native auth mechanism (username and password) we have our own user IDs and issue an authentication token that is used for subsequent interactions after the initial credential validation.
I'm surprised that Facebook doesn't have best practices for this in their developer documentation. All the existing documentation is either assuming you are building FB auth into a website, or a standalone mobile app with no service that requires authentication.
Here's my initial thoughts on how this would be designed but want validation on whether it's correct.
Client pops the Facebook iOS Login
UI User signs in with Facebook credentials and gets access token
iOS App passes access token to our server
Our server talks to FB graph API using access token to (a) validate the token and (b) get the FB user ID for that access token.
e.g. Our server would call https://graph.facebook.com/me/?access_token=XYZ which would return profile info in a JSON object
Assuming it's valid, our server extracts the User ID from the JSON object and checks whether the user already has an account. If so, we issue our own auth ticket to client to use for that session. If user doesn't have an account, we create a new one with the Facebook User ID, assign our own unique UserID and issue our auth ticket.
Client then passes auth ticket back on subsequent interactions that need authentication.
This seems like the right approach to me but not sure if I'm missing something insanely basic and going down the wrong (complicated) path.
I just dealt with this myself, and here's the part that bit me:
In your step 5... It's possible for a user to register for an account with you entirely separate from their Facebook ID, right? Then some other time they log in with Facebook.... And you just created them a second account and lost their first one.
There needs to be a way to be logged in to your web service, then log in to facebook, and capture the association between the facebook ID and the local account.
Apart from that, your plan sounds solid.
Update: Facebook has added a doc outlining such a scenario HERE
Use https to transmit the auth token to your server, as stated by Facebook
Sharing of Access Tokens
Our Data Policies explicitly prohibit any sharing of an Access Token
for your app with any other app. However, we do allow developers to
share Tokens between a native implementation and a server
implementation of the same App (ie. using the same App ID) as long as
the transfer takes place using HTTPS.
One problem I can see with this strategy, is that somebody can give you an access token obtained for a different facebook app. As far as I know, there's no way to verify that the access token is for your application, so you'll just go on and use it.
It doesn't sound very harmful, though. Generally people/apps try to protect the access tokens, rather than sharing them.
One possible exploit of this would be, for somebody to create their own site or mobile app, obtain access tokens for their users and try to authenticate them, using your API. If this succeeds (the user is has a facebook account in your site), the malicious site will be able to use your API impersonating the user.
It's a bit of a long shot, but I think it could work.
Edit: It looks like there is a way to validate the access token after all. See the answer by #Daaniel on question Get application id from user access token (or verify the source application for a token).
your solution totally works.
Maybe an alternative: why not just get the email on the client from the initial social service request and send to your web service? The web service could just store the email, and maybe a social_provider as well. I understand that your web service will not be able to validate where the email came from, but isn't there a high-trust relationship between your web service and your client? If there is, seems like you can depend on the email coming from the right place. Someone please let me know what obvious thing I'm missing that makes the email-based approach silly...
I've read through documentation where possible but unable to figure out this basic question. When using Oauth with Twitter in my web application, does it require the user to be logged into Twitter everytime?
For example, if a user authorises their account with my website, in future sessions, if they complete an action that posts to their twitter stream, will this occur without any problems, or would they need to re-sign in via Twitter?
Thanks guys!
The OAuth authorization actually allows your application to access their account whenever it wants. So the users do not even need to be there doing something with your web application to allow it to tweet something or such.
Your application is then able to use the key and token which it received in the authorization process to tell Twitter any time "hey, I am authorized to use this account" and basically works as the application's personal login credentials for that account.
No, they only need to be logged into Twitter when they go through the initial OAuth authorization. After that, your site talks directly to the Twitter API using tokens that it saved from earlier.
Ok I've setup a test-case and it looks like I was a bit wrong:
oauth_token, oauth_token_secret are unique for each user and they never change, so if you store them in your database you can reuse them. No matter if the user is logged in to twitter or not.
No, they will normally not need to re-authorize. If the token is revoked, however, they will, and your application needs to be able to handle this (by allowing them to do so). In general, this is true for any SSO system.
A twitter user can explicitly revoke an application's token at the provided page.