Page Comparison

...

Clients must be created in the login server and assigned a name, and the URL's used to redirect back to the client must be whitelisted.

Clients can be either confidential (like a server application) or public (like an app or a web application). Confidential clients authenticate themselves with a password. Public client must use PKCE (pronounced "pixi"). Explanations can be found many places, for instance here.

...

But for now an Authorization Server for the inttest environment is available. Its endpoints is described in the contents of this URL: http://a90801479291d11e9865602ac812c206-157159182.eu-west-1.elb.amazonaws.com/auth/realms/inttest/.well-known/openid-configuration

Example authentication

Here is an example URL for an authentication request using HTTP GET, written in a readable format. It should be sent as a single line without spaces or newlines.

 http://a90801479291d11e9865602ac812c206-157159182.eu-west-1.elb.amazonaws.com/auth/realms/inttest/protocol/openid-connect/auth?
  response_type=code&
  client_id=<client_id>&
  redirect_uri=<redirect_uri>&
  scope=openid+profile&
  state=<state>&
  nonce=<nonce>&
  code_challenge=<challenge>&
  code_challenge_method=S256

The parameters have the following meaning:

• response_type=code – indicates that your server expects to receive an authorization code
• client_id= – A client ID that is registered on the Authorization Server
• redirect_uri= – Indicates the URL to return the user to after authorization is complete, such as org.example.app://redirect or a tradition URL for a webapp https://app.example.org/redirect.
• state=1234zyx – A random string generated by your application, which you’ll verify later
• code_challenge=XXXXXXXXX – The code challenge generated as previously described
• code_challenge_method=S256 – either plain or S256, depending on whether the challenge is the plain verifier string or the SHA256 hash of the string. If this parameter is omitted, the server will assume plain.

When the authentication is complete, the browser is redirected back to the given "redirect_uri" (which must be whitelisted in the Authorization Server) including a "code" as a request parameter. This code must be used when calling the token endpoint afterwards.

Here is an example of the following POST request to the token-endpoint.

POST /auth/realms/inttest/protocol/openid-connect/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded

  grant_type=authorization_code&
  code=<code>&
  redirect_uri=https%3A%2F%2Fapp.mysite.org%2Fredirect&
  client_id=<client_id>&
  code_verifier=<secret>

NOTE: For native apps the "redirect_uri" will be a URI with a custom scheme registered to the app on the device, for example "org.example.app://redirect/".