Document OIDC variables

[mpldr]

Document OIDC variables

[ncarlier]

Hi, you are right: it is set during the build time: see REACT_APP_CLIENT_ID configuration variable on the README page.
But it's true this should be more dynamic. I will try to improve this. Using Docker I can try to create a specific entrypoint managing this.

[ncarlier]

With the last update you can configure the client_id at runtime using this configuration. This only works if the UI is served by the main process (https://github.com/ncarlier/readflow/blob/master/pkg/config/defaults.toml#L78).

[mpldr]

Thanks a bunch! Gave it a spin and there seems to be an issue with the processing of the provider URL. Invalid response Content-Type: https://id.moritz.sh/application/o/readflow is turned into https://id.moritz.sh/application/o/readflow/ /.well-known/openid-configuration

[mpldr]

Found the issue, it's in the generated config.js:

const __READFLOW_CONFIG__ = {
    // API base URL, default if empty
    // Values: URL (ex: `https://api.readflow.ap`)
    // Default: ''
    // Default can be overridden by setting ${REACT_APP_API_ROOT} env variable during build time
    apiBaseUrl: 'http://localhost:8080',
    // Authorithy, default if empty
    // Values: URL if using OIDC (ex: `https://accounts.readflow.app`), `none` otherwise
    // Default: `none`
    // Default can be overridden by setting ${REACT_APP_AUTHORITY} env variable during build time
    authority: ' https://id.moritz.sh/application/o/readflow/ ',
    // OpenID Connect client ID, default if empty
    // Values: string (ex: `[email protected]`)
    // Default: ''
    // Default can be overridden by setting ${REACT_APP_CLIENT_ID} env variable during build time
    client_id: 'omitted',
}

The issue being rather obvious.

[mpldr]

Can confirm that login succeeds, but I have no idea what access token readflow is saving. It certainly isn't the ID token my identity server sent. It's significantly shorter and obviously corrupt, when trying to parse it.

The server sent:

eyJhbGciOiJSUzI1NiIsImtpZCI6IjBiZDljYzEwY2Q2ZGUwOWI5MTIxYTdkNDNmOGM5NzQ5IiwidHlwIjoiSldUIn0.eyJpc3MiOiJodHRwczovL2lkLm1vcml0ei5zaC9hcHBsaWNhdGlvbi9vL3JlYWRmbG93LyIsInN1YiI6IjFhZjJkZWVjYmNmZjc0ZTA2ZjE0MGIxMDM3M2QwOTA3ZjM0MzZmMGM5NDUxZmUyNGRmNWM1ZTU5NjNlYmViMjkiLCJhdWQiOiJGOHU4OGpRQ0hPTTZPR0pQUUZGaENRcVU4WjJsWVNPNTFoUzJoOFZiblZid0MyOGtEUUpsZWV4VzNFQnY5bUdVZDZVbDc1ZEpYVkZQeFJaVmtENVBYNzh3SktuNlEyUjRBVkpCcUtNNVU2dEhqclpLSUNIcHBNTFM2cWxJOW41VCIsImV4cCI6MTcwODUyMzk0MiwiaWF0IjoxNzA4NTIzNjQyLCJhdXRoX3RpbWUiOjE3MDQ3MTA0ODUsImFjciI6ImdvYXV0aGVudGlrLmlvL3Byb3ZpZGVycy9vYXV0aDIvZGVmYXVsdCIsImF6cCI6IkY4dTg4alFDSE9NNk9HSlBRRkZoQ1FxVThaMmxZU081MWhTMmg4VmJuVmJ3QzI4a0RRSmxlZXhXM0VCdjltR1VkNlVsNzVkSlhWRlB4UlpWa0Q1UFg3OHdKS242UTJSNEFWSkJxS001VTZ0SGpyWktJQ0hwcE1MUzZxbEk5bjVUIiwidWlkIjoiTmxlTkwzZTRlb1M2WHNhZkpnVFQyOGd0VklOQ0pvakw2WGp3eVJmeiJ9.pA1KTwho-yVDZizHD3RjgLj1AphSDkrYrrMTkKBkoYEVLWM969G1_5ZEKpXAhGzlZDAIFyXjRCzLQVFZsRg6VoPJk-U-TjUleme5ZYSWBDsG_-UJUcE1BSrHr5He9gY5jXT6fxda7gjV9m_TMyjyVTS4NIGOel46_ZF7JE1ozN7OCzfqhy_iwDG2u9WS7qwVf-kVBW3vhjt--DB9eMCw2TnmsI2nr-DxH2lVmtVpHkfvrpfCDAlOoNmcDaCUlPBFNybYzBpvs7io1Cld0r44enmLBk33XQYO6JsbFogsZgOv3TWaqrDlp5GiYXr_jwSDIhIVS0FNm3WcVm4iKv36fhIM4Cpnke4T-C3Icd908onQn56Fhtfg_S51r2W3rQKnUy0Co0DlTh0OcA1mPHDCSLjQI_gr5q_DJxHt33IiBFZTBcbdsviMfb6SFwx7o0I17SYGwqYs81tAzSCzR3cKxRGtWnUWAym0XVogyG7ZWx31VUE64d5Gq5mXm74UaejU4OiRZlMad8tzRnHvmc-dkQfDgfcM8uAUqjVYlFlSajA5gDYidWsVPkK3r89kpdv7kax7bfKC05-nU2Alxt6B3icYmnX_R4SpxuDs5TTVv0r2HO9Vz_wj6WrMxFzonLZZh63KgKbUFMGeoWR2mus8LKJiXZupX7mXs8afQKk6JIQ

Readflow sent this to /graphql:

eyJhbGciOiJSUzI1NiIsImtpZCI6IjBiZDljYzEwY2Q2ZGUwOWI5MTIxYTdkNDNmOGM5NzQ5IiwidHlwIjoiSldUIn0.eyJpc3MiOiJodHRwczovL2lkLm1vcml0ei5zaC9hcHBsaWNhdGlvbi9vL3JlYWRmbG93LyIsInN1YiI6IjFhZjJkZWVjYmNmZjc0ZTA2ZjE0MGIxMDM3M2QwOTA3ZjM0MzZmMGM5NDUxZmUyNGRmNWM1ZTU5NjNlYmViMjkiLCJhdWQiOiJGOHU4OGpRQ0hPTTZPR0pQUUZGaENRcVU4WjJsWVNPNTFoUzJoOFZiblZid0MyOGtEUUpsZWV4VzNFQnY5bUdVZDZVbDc1ZEpYVkZQeFJaVmtENVBYNzh3SktuNlEyUjRBVkpCcUtNNVU2dEhqclpLSUNIcHBNTFM2cWxJOW41VCIsImV4cCI6MTcwODUyNDE4MywiaWF0IjoxNzA4NTIzODgzLCJhdXRoX3RpbWUiO…076jE3D46PRHb8TFHFYk2fyRJaQPzf2CuI_bxC8wZ6JJoY07l3AyCqQ0qbPeZHV0L3KymJjsJA6_6y-2r-kuednacLjHmyZIeEeivmGIEvkw8thuWJOmYUwNtiMR7IlvGPJu2_GYb2f4uDmYCkp05FJDQ6NzzYWmq1CufYM0bM21CorMnnrZDOZDAYtBYCXSrBVl3tm9-sn64B---5bJ6ZH5vaNRIanEhJ5dQr3n0UqaE0O-g8VnTMWIh17XoJLFd5xmKztEtItXbWBI-qG4JfOfTyRU8jj5Ip_EH8zxZKbL2dPie6Ubf07-zEFsPFTgPcR0FMmj9HhpIbSTeb7sJKsoE9w-dXkKqTQXdPwz-8VOZiTHOqVnSxF-ZCHGts-9TW7waVy8_WnnkeshH3aXNHNEw8rF-boQ9m3uWHkKx6ag-jC2ifyr3jHqxQi6wtNh-TOeVYmF3-xNWxdtnEdnF_tsnG52MMnnwxSD4GhndlvSLSLG-SizsdseucCKmjI

The token stored in the session is correct, as far as I can tell.

The corruption looks to me like it's trying to string-encode the payload, but I can't say where in the program this corruption happens.

[mpldr]

Looking at the frontend code, it also looks like it's trying to pass the access token, but the ID token is the one containing ID part of the OIDC. Not good with JS, so I might be misreading things here, though.

[ncarlier]

Sorry about the white space problem. I'll fix it.
Your access token is not corrupted but you have a "..." in the middle. This may be the result of a copy/paste from the Developer Console.
Regarding the cinematic: The frontend simply sends the access_token to the backend. The backend is expecting a JWT access_token. Its payload signature is validated. Its content is then decoded. The backend tries to extract the email or preferred_username claim (or falls back on the ìss claim) to use as the readflow username.
This is simple and efficient, but not suitable when using an opaque or "non-tunable" JWT access_token. To be more compliant, I should call the introspect endpoint to validate an opaque token, then swap the access token with an identification token to extract the username. But this will create a strong coupling with the authentication server and create an extra HTTP call for each API call (unless we add a cache or something).

[mpldr]

I got this token by clicking "Copy Value", which apparently truncated it… What the hell? You're correct. The full token got sent.

The frontend simply sends the access_token to the backend. The backend is expecting a JWT access_token.

Yes, and per OIDC spec. The access_token isn't the one supposed to hold the username. That's the ID_Token (see example from OIDC Spec). And falling back to the token issuer as the username doesn't really make sense either… shouldn't it be sub?

[ncarlier]

Last commit improve OIDC support. Username is fetched from multiple locations (JWT or introspection or User Info endpoint).