I do agree that OIDC is not a terribly complicated standard, but with any standard there are always little gotchas that are not apparent. I too am not a security expert and don't want to put something out there that people think is a secure piece of code and have it compromised because of something I never thought would be a problem.

Writing security code is not really a trivial matter as you probably already know and making a requirement that the standard OIDC module can not be used in favor of reimplementing it is just lunacy to me. But if that is your intent, then we can go ahead and close this PR and I will keep the branch for myself and merge it will future versions of Readeck for my use.

This will probably be pulled out anyways as it appears that when the NewProvisioner() function in the go-oidc module retrieves the JSON document stored on the authentication server to configure the client.

Once the OIDC authentication flow is initiated by the user pressing the OIDC login button, a random string is generated and sent to the OIDC authentication server. This is usually referred to as the state in the OIDC flow and is really used to validate that the authentication request was initiated from the application is really just a CSRF token. The application upon receiving a login request, will perform an HTTP redirect (GET) to the authentication server with a state, client_id, scope, response_type and request_uri parameters.

The client_id is generated on the authentication server to identify which application is requesting authentication. This is a static token that is stored in the application's configuration. The scope tells the authentication server what claims are requested by the application in the authentication response. This is commonly set to 'openid profile email'. openid is require and the profile requests items such as username and UID and of course email requests the user's email address. response_type is set to 'code' to (I believe) request an access token in the response. Finally the redirect_uri is the URL that the authentication server needs to send the response.

The user will then authenticate to the OIDC authentication server if necessary and the authentication server will return to the application using the redirect_uri which will be called with the state and code parameters. Again the state is used to validate that the request originated from the application so the returned state value needs to be compared to the stored state value when the authentication request was initiated. The code (which depending upon the OIDC implementation could be a string or a JWT) is then exchanged for the access and ID tokens. This is done by calling the OIDC token endpoint with the code value. The response will be a JSON document that contains these tokens and a few other items such as expiration time for the tokens.

The ID token is used to authenticate the user and should be used to validate the user. The access token is used for authorization and provides information as to what the user has access to. In my case I am using Authentik and both the ID and access tokens are very similar, but that may be because I don't have a lot of settings in Authentik that would provide different authorizations.

The payload for the ID token asserts the following claims:

{
  "iss": "https://auth.wt0f.com/application/o/readeck/",
  "sub": "hickey",
  "aud": "H9uYxz2H6czUt08O0gZroxIAAUYj5hy0lgaM2IRg",
  "exp": 1775680621,
  "iat": 1775680321,
  "auth_time": 1775666408,
  "acr": "goauthentik.io/providers/oauth2/default",
  "amr": [
    "pwd"
  ],
  "sid": "d582cf9de4038d38e8dd095b1d892b83efa6fab7ced7b9e004f58b5d1ffbc6c3",
  "jti": "FFG2mtCp0Py1wVdKT8SUIt294yqZ9jAzePXEYkOK",
  "email": "hickey@kinetic-compute.com",
  "email_verified": false,
  "name": "Gerard Hickey",
  "given_name": "Gerard Hickey",
  "preferred_username": "hickey",
  "nickname": "hickey",
  "groups": [
    "authentik Admins",
    "NextCloud Admins",
    "Grafana Admins",
    "Proxmox-Admins",
    "Authentik Admin Tools",
    "Authentik Backend Services"
  ]
}

The claims in the access token is as follows:

{
  "iss": "https://auth.wt0f.com/application/o/readeck/",
  "sub": "hickey",
  "aud": "H9uYxz2H6czUt08O0gZroxIAAUYj5hy0lgaM2IRg",
  "exp": 1775667590,
  "iat": 1775667290,
  "auth_time": 1775666408,
  "acr": "goauthentik.io/providers/oauth2/default",
  "amr": [
    "pwd"
  ],
  "sid": "d582cf9de4038d38e8dd095b1d892b83efa6fab7ced7b9e004f58b5d1ffbc6c3",
  "jti": "mGOpPVJBVBXyz5DTQvyEct54NOcHXX1OFyw398YR",
  "email": "hickey@kinetic-compute.com",
  "email_verified": false,
  "name": "Gerard Hickey",
  "given_name": "Gerard Hickey",
  "preferred_username": "hickey",
  "nickname": "hickey",
  "groups": [
    "authentik Admins",
    "NextCloud Admins",
    "Grafana Admins",
    "Proxmox-Admins",
    "Authentik Admin Tools",
    "Authentik Backend Services"
  ],
  "azp": "H9uYxz2H6czUt08O0gZroxIAAUYj5hy0lgaM2IRg",
  "uid": "bADM3vh0ws6dp2s5f8fb46fh8i2tawMGToExAL3T",
  "scope": "profile email openid"
}

As one can see, both of these tokens are very similar but they are representing different needs for the application. Both JWTs are signed by the private key of the authorization server and gets verified by retrieving the public key from the authorization server.

At this point the application can continue with the authenticated user as if the user had logged in with another method. At some point in the future the access token will expire and a new access token will need to be retrieved from the authorization server. This aspect I don't have as much visibility into yet. There are references to a refresh_token that is included in the response that provides the access and ID tokens, but I am not receiving this from my Authentik server. It could be that Authentik does not provide a refresh_token or it is a matter of the configuration I have in the Authentik for the application. I am not sure which. Once I have the user being created/loaded I will be able to experiment and learn what needs to be done to generate new access tokens.

This extends Drop.Load() with support for HTML Refresh directive specified either via HTTP response header or via <meta> tag.

Fixes #1179

TODO:

• Is Drop.Load() the correct place to implement this?
• Should we set the HTTP Referer header when following this type of redirect? (The spec suggests we should.)
• Set maximum redirect limit to prevent infinite redirect loops
• Clean up the extension of the tinymeta package

Did you write it yourself?

I didn't use any AI tool to produce this contribution.

Did you add tests?

I added tests to my contribution

Did you run the tests?

The tests finished successfully

However, since nearly every browser out there is able to install the Readeck browser extension, which offers a much better and complete experience of sending web pages to Readeck than a bookmarklet ever could, I'm wondering whether there is even a use-case for a bookmarklet over the browser extension? What do you think?

Support saving pdfs, and displaying them in bookmarks.

Did you write it yourself?

I didn't use any AI tool to produce this contribution.

Did you add tests?

I added tests to my contribution

Did you run the tests?

I didn't run the tests

This code is an attempt to add the OIDC authentication flow to Readeck to allow external authentication with an OIDC provider. The code contained here in has been developed using an Authentik server and the running code is hosted at https://rd.wt0f.com/. I am happy to add an account on my Authentik server for developers that wish to test or investigate this code. Please leave a comment in this PR requesting an account to be setup.

I have made an effort to make sure that this code confirms to OIDC Core 1.0 specification. This is a new area of knowledge for me (hence why I decided to work on it) and something I was wanting in Readeck.

@mislav, it is my understanding that you have also done some work toward adding OIDC authentication to Readeck, so I welcome any comments or thoughts that you have.

Did you write it yourself?

I didn't use any AI tool to produce this contribution.

Did you add tests?

No response

Did you run the tests?

I didn't run the tests