Hi,
I would like to know how I must set the redirect uri, server-side, to satisfy the rfc 8252
https://tools.ietf.org/html/rfc8252

Below is the extract from the rfc.

7.3 Loopback Interface Redirection

Native apps that are able to open a port on the loopback network
interface without needing special permissions (typically, those on
desktop operating systems) can use the loopback interface to receive
the OAuth redirect.

Loopback redirect URIs use the "http" scheme and are constructed with
the loopback IP literal and whatever port the client is listening on.


That is, "http://127.0.0.1:{port}/{path}" for IPv4, and
"http://[::1]:{port}/{path}" for IPv6. An example redirect using the
IPv4 loopback interface with a randomly assigned port:

http://127.0.0.1:51004/oauth2redirect/example-provider

An example redirect using the IPv6 loopback interface with a randomly
assigned port:

http://[::1]:61023/oauth2redirect/example-provider

The authorization server MUST allow any port to be specified at the
time of the request for loopback IP redirect URIs, to accommodate
clients that obtain an available ephemeral port from the operating
system at the time of the request.

Clients SHOULD NOT assume that the device supports a particular
version of the Internet Protocol. It is RECOMMENDED that clients
attempt to bind to the loopback interface using both IPv4 and IPv6
and use whichever is available.

On ISVA 10.0.8 I tried both the examples shown and was able to set them. I don't know for sure, and don't have a 10.0.1 system available (which is now very out of date), but perhaps this has been addressed in a version newer than what you are using?

Hi,
I would like to know how I must set the redirect uri, server-side, to satisfy the rfc 8252
https://tools.ietf.org/html/rfc8252

Below is the extract from the rfc.

7.3 Loopback Interface Redirection

Native apps that are able to open a port on the loopback network
interface without needing special permissions (typically, those on
desktop operating systems) can use the loopback interface to receive
the OAuth redirect.

Loopback redirect URIs use the "http" scheme and are constructed with
the loopback IP literal and whatever port the client is listening on.


That is, "http://127.0.0.1:{port}/{path}" for IPv4, and
"http://[::1]:{port}/{path}" for IPv6. An example redirect using the
IPv4 loopback interface with a randomly assigned port:

http://127.0.0.1:51004/oauth2redirect/example-provider

An example redirect using the IPv6 loopback interface with a randomly
assigned port:

http://[::1]:61023/oauth2redirect/example-provider

The authorization server MUST allow any port to be specified at the
time of the request for loopback IP redirect URIs, to accommodate
clients that obtain an available ephemeral port from the operating
system at the time of the request.

Clients SHOULD NOT assume that the device supports a particular
version of the Internet Protocol. It is RECOMMENDED that clients
attempt to bind to the loopback interface using both IPv4 and IPv6
and use whichever is available.

Hi Shane,

Thank you for your reply, even in version 10.0.1 it is possible to insert those redirect uri, but I think that since they have a specific port inside, they will only work if invoked on that port.
I am looking for a solution and I think I will have to enable local-response-redirect in the webseal configuration file, and set in the something like http://127.0.0.1/callback in the Oauth definition client

Right now unfortunately I don't have an FE client that works on random ports, and i can't try this solution.

I will let you know

Regards.

Fabio Morziello

On ISVA 10.0.8 I tried both the examples shown and was able to set them. I don't know for sure, and don't have a 10.0.1 system available (which is now very out of date), but perhaps this has been addressed in a version newer than what you are using?

Hi,
I would like to know how I must set the redirect uri, server-side, to satisfy the rfc 8252
https://tools.ietf.org/html/rfc8252

Below is the extract from the rfc.

7.3 Loopback Interface Redirection

Native apps that are able to open a port on the loopback network
interface without needing special permissions (typically, those on
desktop operating systems) can use the loopback interface to receive
the OAuth redirect.

Loopback redirect URIs use the "http" scheme and are constructed with
the loopback IP literal and whatever port the client is listening on.


That is, "http://127.0.0.1:{port}/{path}" for IPv4, and
"http://[::1]:{port}/{path}" for IPv6. An example redirect using the
IPv4 loopback interface with a randomly assigned port:

http://127.0.0.1:51004/oauth2redirect/example-provider

An example redirect using the IPv6 loopback interface with a randomly
assigned port:

http://[::1]:61023/oauth2redirect/example-provider

The authorization server MUST allow any port to be specified at the
time of the request for loopback IP redirect URIs, to accommodate
clients that obtain an available ephemeral port from the operating
system at the time of the request.

Clients SHOULD NOT assume that the device supports a particular
version of the Internet Protocol. It is RECOMMENDED that clients
attempt to bind to the loopback interface using both IPv4 and IPv6
and use whichever is available.