This PKCE link is helpful, thank you! Let me see if I have this straight… in the first case (e.g. the one used by Ueberauth), the server backend (e.g. Phoenix) ends up with a token which (after exchanging it) can be used to make further requests, whereas in the JS variant, the client ends up only with a JWT which vouches for the user and basically proves that the user is who they say they are (the client just has to verify the signature on the JWK to prove that it has not been tampered with).
I don’t recall having to define a client secret or code challenge, however… I’m also looking over https://auth0.com/docs/flows/concepts/auth-code-pkce – but I don’t follow all the steps that it diagrams.
I’ve done Facebook OAuth setups – they work the same way as the Ueberauth example with a token sent to the redirect URL that has to be exchanged before it can be used to make calls against the Facebook API. Twitter uses (used?) OAuth1, but it was the same type of flow.
I’m not aware of other authorities that will cough up a JWT as a “by-product” of logging in, which the client can then verify.
