Comment by rahulrav | Hacker News Reader

Comment by rahulrav | Hacker News Reader

Unfortunately, Apple Sign In for the Web - insists on using HTTP POST's for the redirect_uri. This is a snippet from their official JavaScript library.

const t = { baseURI: "https://appleid.apple.com", path: "/auth/authorize", originURI: "", env: "prod", uxMode: "redirect", responseType: "code id_token", responseMode: "form_post", client: { clientId: "", scope: "", redirectURI: "", state: "" } };

Notice the responseMode which is set to form_post which I believe is the only supported mode.

This means you can no longer do things like localhost redirect_uri's for testing, or even use Apple Sign In on an internal web-app. Also, goes against OAuth2. :(

I submitted this feedback. Hopefully, someone takes a look.

> This means you can no longer do things like localhost redirect_uri's for testing, or even use Apple Sign In on an internal web-app.

Seems this might provide some security benefit, e.g. no credentials showing up in web server access logs. Either way, are you sure the final POST isn't made by the client? If so, the client would resolve the address. On their JS configuration page[1], I don't see any obvious evidence that Apple will make the post. They show this line:

`AppleID.auth.signIn();`

P.S. Aghghgh the mixed camelCase and under_score makes me cringe.

  [1] https://developer.apple.com/documentation/signinwithapplejs/configuring_your_webpage_for_sign_in_with_apple

They already don’t show up if you use fragment URIs. The real issue I have is that the OAuth2 spec covers all this and we don’t have to rehash this every time a new IDP creates an Auth system.

No. The final post is not made by the client and a server has to handle the request. Webapps cannot handle POST requests from an Authorization server.

Reply on news.ycombinator.com