I know that this is something like a 'RTFM' question, but I can't for the life of me find solid documentation about this.
Specifically, I have a service that uses google's oauth2 REST api to authenticate users. The library I'm using (bell), recently started making calls to the /v2 version of the API endpoint. Those calls no longer seem to support approval_prompt=force in the querystring (or something along those lines, I'm no longer able to use a special route to force a new refresh token).
Realistically, all I need to do is read the documentation for what changed from v1 to v2 of the oauth2 library, or even find v2-specific information. All the documentation on developers.google.com seems to be about the v1 api.
There is no documented list of changes at present. The main changes from/auth to v2/auth, and v3/token to v4/token is that the newer versions are certified compliant with OpenID Connect. The earlier versions had a few inconsistencies with the spec, mostly because when Google launched them the spec was not yet final.
approval_prompt is now prompt. To get your approval_prompt=force behavior on the newer endpoint, specify prompt=consent. Other values for the prompt parameter are defined in section 3.1.2.1 of the spec.
Other changes, in no particular order:
the ID Token iss value is now https://accounts.google.com, was accounts.google.com
nonce is required for implicit and hybrid flows
ID tokens on the newer endpoints may contain profile claims (if the profile scope was requested), saving a call to userinfo.
Related
We are using Go server side code to interact with Google Ads REST API.
Namely, we authenticate it with help of "golang.org/x/oauth2" and
"golang.org/x/oauth2"packages.
In May (and recently again) we've got a email from Google regarding deprecation
Out-of-band flow, essentially rewording of this
one.
But additionally to common information, Google email listed account, which we
are using to authenticate, as being used in OOB flow and going to be blocked.
We checked our sources and available sources of mentioned packages but was not
able to find redirect URIs which are said to be used for OOB flow as one of
those:
redirect_uri=urn:ietf:wg:oauth:2.0:oob
urn:ietf:wg:oauth:2.0:oob:auto
oob
We explicitly use http://localhost in our code and long-live refresh token
(which seems never expires).
We also tried to use tcpdump to monitor our API calls, but was not able to
learn much from it, because calls are made via https and, therefore, encrypted.
We considered to use man-in-the-middle kind of proxy like
https://www.charlesproxy.com/, but haven't tried it yet, because it become
non-free and because of complexity of setup.
We tried to log our requests to API endpoint with custom RoundTripper, but
have not spotted anything suspicious. It seems that we're using refresh token
only and exchange of code to refresh token just never happen in the code.
Because of this, we don't think that further logging or monitoring with
decrypting https packages may help (but we open to suggestions how to do it better).
Finally, we decided to create a new OAuth 2 Client in the Google console with
fresh set of client id, client secret and refresh token. We obtained a new
refresh token with oauth2l and replaced
credentials in our configuration. But still, we are not sure that new account
will not be blocked by Google due OOB deprication, because seemingly it looks
the same as old one.
Questions:
Why may Google mark our account as OOB?
How can we ensure that newly created account will not be blocked?
Same here.
I find out an answer, that says "Desktop" type of Credentials uses OOB by default. Probably you need to create new Credentials with type "Web"
I was trying to setup OAuth workflow using the sample application as given here
However for some reason, after I enter my okta user Id and password, I never gets the control back on my call-back URL and application just hangs indefinitely.
However the normal Javascript Singn-in widget (check this link) with the minimal authentication does work and I get the control back to the redirect URL. But this is not for an OAuth2 workflow... which is completely useless for me. Because all it does is provide authentication service using Okta tenant app and it will redirect you to your App URL. This does not provide any authorization grant workflow or other OAuth2 complex workflow. May be useful for some application but not for enterprise app where you want to retrieve user profiles, and create a login session based on user profile data retrieved from OKTA.
So my question is why is the OAuth workflow not working using the PHP application that uses JS sign-in-widget? And why there are no instructions or warning on this page for this costly service (this is not free and many org is probably paying for this)?
I spent almost a day trying to setup my Authorization server as per the instruction given on this link, but nothing works. Any idea what must be going wrong ?
Does this entire example works only after contacting OKTA support to enable the Authorization server feature? Because, I also saw a documentation here that says that this is Early Access (EA) feature (and it is probably recently added in OKTA? Extremely frustrating experience).
BTW I sent email to their customer support to enable this Authorization server feature just in case if I am missing something. If this does not work then I will have to create my own OAuth2 server using Laravel 5.4 PHP framework, which is probably the quickest solution and 100% free.
I also tried to test the Authorization server setup as per the instructions provided here.
I was successful in getting the following end point working:
/oauth2/:authorizationServerId/.well-known/openid-configuration
But I am unable to get any scope and claims using api end-point:
/api/v1/authorizationServers/:authorizationServerId/scopes
So in short, I am so far unable to test my Authorization server to get my authorization grant workflow working.
Where can I look for some troubleshooting advice?
Is there another way to check whether I have configured my OKTA Authorization server properly?
I found out that the JS script provided for the PHP sample is not right for the workflow I am working on. So after changing that JS Script, things started to work.
Edit: Also please note that Setting up Authorization server is a new feature (It is Early Access feature) in OKTA. It is not enabled by default. So you need to contact OKTA support team to enable the Authorization service endpoint and functionality provided by it.
We have a .Net Web API (v2) serving an SPA that I aim to secure using OAuth 2.
In my OWIN Startup.Configuration(), I set my Provider in IAppBuilder.UseOAuthAuthorizationServer to an override of OAuthAuthorizationServerProvider. I have this successfully providing refresh tokens.
I want to be sure that these tokens cannot be spoofed by someone implementing a similar provider. No searching I have done has given me any kind of answer.
Does OAuthAuthorizationServerProvider ensure that the refresh tokens received are those issued by itself, and not any similar code on a hacker's machine?
My own experiment seems to confirm that it does - I tried the same code running on two different machines and took the unexpired refresh token (with a long expiry of 24 hours) from the other machine, and got a 401 as I'd hope. But just in case I've wrongly convinced myself, I'd like some reassurance and/ or advice from someone who knows more about OAuth in the .Net Web API than I.
Thanks,
Paul
I'm sure I eventually found a definitive answer in the doc for OAuthAuthorizationServerProvider but now can't find it.
However, Dominick Baier, an expert in this field, says:
Access tokens are protected using the machine key. Protection of refresh tokens is up to you. You need to manually set the machineKey element in web.config (otherwise the key gets auto generated and might change over time).
His comment comes from a reply to a post on implementing OAuthAuthorizationServerProvider.
I downloaded the WIF Extensions for SAML2 a few days ago and have been experimenting with them. The samples in the download use a WebForms application, and I am trying to figure out how to use them in MVC3.
I am currently able to auth against the sample Identity Provider that comes with the download, using this:
Saml2AuthenticationModule.Current.SignIn(
"~/sign-on/saml2/success", "urn:samples:identityprovider");
I have an action method at the "sign-on/saml2/success" route / URL, and when the application flow reaches it, the Thread.CurrentPrincipal.Identity is indeed an instance of IClaimsIdentity. Although the Identity.IsAuthenticated equals true, the Identity.Name is an empty string. (This will be problematic in our app, which so far has used FormsAuthentication, and relies on Identity.Name to resolve to a user account in the db.)
I also see that there are 4 new cookies at this point:
FedId
FedAuth
FedAuth1
[fourth cookie name is a GUID, changes for each SSO]
My inclination at this point is to delete these 4 cookies and use the claims NameIdentifier to create a new account in our app (unless one already exists), and then use FormsAuthentication to write a .ASPXAUTH cookie for the user.
The first affiliate IdP we will be integrating with uses Shibboleth, and they do not yet implement SingleLogOut. So my assumption is that the following would have no effect when we begin testing this integration:
Saml2AuthenticationModule.Current.SignOut("~/sign-off/saml2/success");
So, manually deleting the 4 cookies is the only way we would be able to get the Identity.IsAuthenticated back to a false value.
Am I going about this in an incorrect fashion? Are there any implications of trashing the IClaimsIdentity after it has been consumed and transferred to FormsAuthentication, that I am not considering?
I'm trying to move my web application to the Google Chrome store, and I want to charge for premium features. The problem is, to use the Chrome Web Store License API I need their Google OpenID identifier. I've read other similar questions, but none with code examples.
I found this example, but it seems to be for a different purpose.
So my question is, how do I use the Federated Login in a Sinatra / Rack environment to get that one parameter?
Thank you.
You need to authenticate users with OpenID. The link has an example that shows how to use Rack::OpenID.
With Google, instead of requesting the openid_identifier from the user you would need to hardcode https://www.google.com/accounts/o8/id as identifier (instead of params["opened_identifier"]) then run normal OpenID.