verifyAssertion fails with 400 - Bad response from IDP

[Don Parakin]

So, I'm going crazy trying to get Gitkit to work.  I have followed the steps for quick start .  I get the "Sign In" button.  When clicked, I get page with the widget.  When I enter my gmail id press enter, I get "400 - Bad response from IDP".  My only IDP is Google, and I have enabled Google+ API (per other thread).  I tried many combinations and permutations of Identity API and OAuth2 credential settings, but they all fail the same.

Here's the failing POST request to (reformatted for readability) ...

URL = https://www.googleapis.com/identitytoolkit/v3/relyingparty/verifyAssertion?key=AIzaSyD...REDACTED...wPOY

BODY = {"requestUri":"http://local.mywebsite.com/sign-in#/

    state=AFD_5tkQfJMM...REDACTED...TvvDeG5Z4CTl0OV_iw

    &id_token=eyJhbGci...REDACTED...vK5pWSv0x0Bnnm7OyGJhk8KGvpxqTw

    &authuser=0

    &session_state=364...REDACTED...5ad8a25ad0ab912f..6783

    &prompt=none",

"postBody":""}

and here's the response ...

BODY = { "error": { "errors": [ {

    "domain": "global",

    "reason": "invalid",

    "message": "Bad response from IDP"

   } ],

  "code": 400,

  "message": "Bad response from IDP"

} }

• Q1:  I'm developing on my laptop using a local instance of Apache (unreachable from external sites).  Could this prevent the sign-in flow from working?
• Q2:  The API referenece for verifyAssertion is a little light on info.  Is it okay to omit "pendingIdToken" from the request (as above)?  For "postBody", is "" okay?  The ref says "The post body if the request is a HTTP POST".  Which request? to which server?
• Q3:  Is there any way to get some more useful debug info?  I've noticed the online samples load gitkit-debug.js instead of gitkit.js: tried that but got nothing in the console, etc.  Is it the Identity API or the Google sign-in API that is not being generous with usable debug info?

[Jin Liu]

Hi Don,

Can you send me the complete http POST request which causes 400 error? The POST request contains the login user info, so please uses a test account and send to me in private (select the "Reply privately to author" from the dropdown menu).

Regarding your other questions,

1. A local web server should work.

2. The VerifyAssertion API is meant to be called from Google Identity Toolkit javascript/mobile SDK, but I agree the document could be improved. The pendingIdToken and could be omitted and postBody can be empty.

3. We would like to return helpful error message without leaking sensitive information to attackers. Once the reason for this 400 error is clear, we will have better idea about what error messages might be helpful. 

[Don Parakin]

Jin, many thanks for your support (and the ongoing awesome support you give in this forum)!

I tried a test gmail account and it worked!!! ... or at least it took me to the Google Account Chooser page where I already have 4 Google accounts defined.  Until then, all my test had been with my personal gmail account.  I tried the other accounts on my Account Chooser list and got varying results.  3 of the 4 would return 400 error for the POST (2 were gmail; 1 was GA4W (Google Apps for Work)).  1 of the 4 (a GA4W id) would work correctly and would prompt for my password.  Very strange.  Here's the 400 POST request for the GA4W account that did not work ... (sent via private message)

[Ying Hao]

Hi Don,

It looks to me like a setting issue. Could you please try the following:

1. go to console.developers.google.com/project

2. find the project that enabled Identity Toolkit

3. At Identity Toolkit API settings page, check if the checkbox next to Providers | Google is checked.

4. If it is not checked, click to check it.

5. Click on save(no matter you did 4 or not).

Let us know if it works.

[Don Parakin]

Hey, Ying.  Google provider was already checked in my Identity API settings.  

I thought I'd try your instructions by first setting Google to unchecked.  I unchecked Google and saved it.  Looked okay except when I went to the project's home page and then back into Identity API, the Google provider was still checked.  When I click the "Save" button I do not get an error but I also do not get any confirmation that it saved correctly (except that the JSON code at the bottom now only lists "password" as an provider).  I tried this several times.  Every time I come back in, Google is selected as a provider.  

After several attempts to de-select Google and saving ... I tried to sign-in process again: I am still getting 400 - Bad response from IDP.

[Don Parakin]

Okay, found the problem.  First, let me thank Ying Hao and Jin Liu for their excellent support resolving this offline.

The problem is related to running AngularJS in hashbang mode instead of HTML5 mode.  Hashbang mode is where AngularJS has "#" or "#!" in the middle of URLs to indicate the beginning of the "routes" or sub-pages within the single-page-app.  Hashbang mode is required for older browsers like IE9 that do not support the HTML5 History API.  Here's the problem ...

• The Open ID Connect specification says IDPs should respond to an id_token request with a redirect URL that contains a "#" before the query string name/value pairs.  I don't know why they didn't want to use the usual "?" before the URL's query string.
• Google IDP, as required by the spec, replies with a "#" before the query string.
• AngularJS sees the "#" and adds a default route "/" after the "#" (I think).  This messes up the Gitkit code and causes it to send a bad request.

If you are using HTML5 mode, you won't have this problem, but you also won't support older browsers like IE9 that don't support the HTML History API.  If, like me, you must support IE9 (d-oh!) then I don't have a fix yet.

[Mengcheng Duan]

Don, glad to see your issue is resolved and thank you very much for the summary.

The use of fragment (#) instead of query (?) parameter for an IDP to return an ID token or access token is indeed required by OpenID Connect spec and it's for good reasons. Query parameter can be leaked during transport, e.g., logged by a proxy, or shared with others by Referer HTTP header while fragment parameter is not subject to these risks. You can find more information in OAuth 2.0 Multiple Response Type Encoding Practices spec. 

- Mengcheng

--
You received this message because you are subscribed to the Google Groups "Google Identity Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-identity-t...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Don Parakin]

Mengcheng, thanks for your reply.  My issue is not yet resolved (or solved), just the root cause is now known.  Thanks for the technical reasons for OIDC using "#" instead of "?": it makes sense.

But that still leaves us in the situation where Gitkit does not work with AngularJS in hashbang mode.  Hashbang mode is AngularJS's default mode, is the mode needed to support older browsers like IE9, and is the fallback mode for the HTML5 mode if it cannot work for any reason.

Is this situation okay?  Or does it make sense to try to get Gitkit working with AngularJS/hashbang given AngularJS's popularity (if not dominance) for web apps (apps are what need user-auth the most, unlike brochureware sites where jQuery will do)?  I think it does make sense to try.

Trying to change the OIDC spec or getting all the IDPs to change does not make sense (too hard; too time-consuming; too futile).  That leaves Gitkit.  Fortunately, there are 2 opportunities where Gitkit code has access to the "bad" URL before it is sent to the IDP.  gitkit.js running in the browser uses the "bad" URL in window.location to create the request it sends to Identity Toolkit code (running server-side on www.googleapis.com/identitytoolkit); the Identity Toolkit code (running server-side) processes then sends the request to the IDP.  Both gitkit.js and the server-side Identity Toolkit code have an opportunity to fix the "bad" URL before its sent to the IDP.  I can imagine several cunning designs, perhaps using a new "angular" parameter if needed, that could fix the "bad" URL before its sent to the IDP.

Until this issue is resolved, AngularJS/hashbang users such as myself cannot use Gitkit :( 

Many MANY thanks for your time and help with this issue.

---- Don P