Currently all the providers create a config and then they all do exactly the same thing, create an OAuth2Client instance using that config, this ties deno_kv_oauth to the existing oauth2_client API quite tightly.

An OAuth2Client contains an amount of redundant features that are not used by deno_kv_oauth (ie. implicit, ropc, clientCredentials), also you never need both code and refresh together.

If the providers just returned the config, and this config was passed to signIn/handleCallback etc, those fns could then create the client, and allow for future evolution of the client API or even a completely alternative oauth2 lib.

Users of deno_kv_oauth need not care about the underlying client lib at all, they'll just be exposed to the config interface.

host is up to debate, just the base URL of the gitlab instance for those who self-host.

The current codebase likely supports this. A working example would provide validation.

Once the ID token is available from providers that support OpenID Connect, it would be useful to be able to get the URL for the public JSON Web Key Set from the provider too so we can verify the id token using whatever JWT lib we want.

I don't know if this is possible. We might have to pass around requests and responses instead.

All entries from tests should be cleaned up after all tests are complete. This needs to be confirmed that this is the case.

It should:

• Import handler() from demo.ts and use serve() from std.
• Use the signal property to close the server once tests are completed.
• Basically, ensure the demo server starts fine and endpoints are responsive, but provide 100% test coverage, if possible. In-depth testing of deno_kv_oauth's functions is not needed, as that's taken care

A working demo should be done to confirm that this module supports multiple providers simultaneously.

https://discord.com/channels/684898665143206084/991511118524715139/1149096912566354011

I've made the issue here but as this package depends on it and the docs show Auth0 being supported wanted to bring it to your attention too.

Auth0 will return an invalid JWT unless the audience is added to the Uri. Looking at the code it doesn't seem that there's currently a way to allow this

The demo should be minimal and roughly look like the demo in this repo. Once created, a link to the demo repo can be added to the "In the Wild" README section. See the Oak + Deno KV OAuth Demo for reference.

I have enjoyed using this library for handling sessions. However I have noticed that at some point there will be sessions that don't get deleted from the the store and so overtime could grow and will need a way to delete them.

As I understand the Kv store API currently doesn't have and true TTL capabilities natively but I think it should be possible to still expose a way to search/filter sessions by expiry time.

The official docs state this:

- A range selector selects all keys that are lexicographically between the given start and end keys (including the start, and excluding the end). For example, the selector ["users", "a"], ["users", "n"] will select all keys that start with the prefix ["users"] and have a second key part that is lexicographically between a and n, such as ["users", "alice"], ["users", "bob"], and ["users", "mike"], but not ["users", "noa"] or ["users", "zoe"].

Based on this I think if a key included a timestamp (could be [PREFIX, timestamp]) then could expose a function like getExpiredSessions that may look like this:

const db = await Deno.openKv();
const entries = db.list({ start: [KV_PREFIX, 0], end: [KV_PREFIX, unix_timestamp] })
for await (const entry of entries) {
  entry.key; // [KV_PREFIX, expiry_as_unix]
  entry.value; // { sessionId, expiryAsUnix, ...rest }
  entry.versionstamp; // "00000000000000010000"
}

I'm unsure on the deleteExpiredSessions method but I think it would need to use transactions for consistency.

Be interested to open the dialogue to see other opinions on the matter.

I saw this bit of code and felt it may be a good starting point

I've been experimenting with deno_kv_oauth to provide a sign in for my personal site, I've created a handful of functions to discover available providers, and to dynamically configure providers based on the environment vars that have been set...

https://github.com/jollytoad/home/blob/main/lib/oauth2_clients.ts

• getOAuth2ClientNames - Get a list of all supported OAuth2 client names
• hasOAuth2ClientEnvVars - Detect whether environment vars have been set for a given OAuth2 client
• getOAuth2ClientFn - Get the create client function for an OAuth2 client given it's name
• getOAuth2ClientScope - Get the OAuth2 scope for a provider from environment vars

Would you be interested in having some or all of these fns within deno_kv_auth itself?
I'd be to raise a PR for this if so, and include some tests.

For an example of usage, see... https://github.com/jollytoad/home/blob/main/components/UserWidget.tsx
This JSX component lists sign in links for providers where the env vars have been set, using getOAuth2ClientNames & hasOAuth2ClientEnvVars, the sign in link includes the provider name in the path, and https://github.com/jollytoad/home/blob/main/routes/auth/_lib/oauth2_client.ts has a function used by the signin/callback handlers to extract the provider name and use getOAuth2ClientFn & getOAuth2ClientScope. (All of this stuff is specific to my site though, so I wouldn't suggest incorporating these, I'm referencing them simply as an example of usage)

The demo should be minimal and roughly look like the demo in this repo. Once created, a link to the demo repo can be added to the "In the Wild" README section. See the Oak + Deno KV OAuth Demo for reference.

Okta docs: https://developer.okta.com/docs/reference/api/oidc

PR to follow very shortly.

See https://github.com/denoland/deno_kv_oauth/actions/runs/5273258573/jobs/9536459555?pr=84

I came across a new Deno framework and was attempting to use the package for auth. seems I am having issues with a response. The author says that the ctx.req.raw object is a standard Request and that did work for the signIn leg, but for the callback seems to just not do anything. I am looking into this

issue: add support for denoland/deno_kv_oauth · Issue #133 · azurystudio/cheetah (github.com)

This module getting the user object is doing too much. Instead, we can get the stored authenticated tokens from the session ID. This will also mean a simpler API.

• #7
• #8
• #13
• #42

For use case like denoland/saaskit#249

The Fresh plugin will now live within the Fresh repo (denoland/fresh#1733).

@mbhrznr will take this one.

See the following for guidance:

• https://github.com/denoland/deno_kv_oauth#adding-a-pre-configured-oauth-20-client for guidance.
• #110

I searched all the existing issues and docs, I was only able to figure out, how to get the sessionId or accessToken.

How can one get user details from accessToken? Should we connect to 3rd party APIs separately?

handleCallback() sets a site session cookie in the response. This cookie should be configurable but with reasonable defaults.

Closing as this might be able to be done somewhere else. See #23 for context.

Most of the supported providers aren't available / are unreliable in China

kv_oauth sits atop oauth2_client, but exposes much of the inner workings of oauth2_client, this I feel is a leaky abstraction in that it leaves kv_oauth at risk from major oauth2_client API changes, and prevents (however unlikely) future consideration of alternatives, or even direct inclusion of just the essential parts of that lib should it ever become unmaintained.

One way to address this is to pass config rather than client as addressed by #174, but it's been discussed that the config adopts OAuth2ClientConfig directly.

There are three issues I have with this interface:

1. It's exported from a module that also contains the OAuth2Client class, placing a dependency burden on anything that wants to reference this type
2. It exposes a number of options that could be deemed unnecessary (at this time at least) for a highly level lib like kv_oauth, namely: defaults.requestOptions & defaults.stateValidator
3. If we discard those, this leaves us with defaults.scope which feels unnecessarily nested

My proposal is for kv_oauth to expose it own config type that better fits it use case and developer experience, exposing only options that are necessary for kv_oauth, and to protect it from potential future changes, abandonment, or even the consideration of alternatives to the underlying oauth2_client API.

I feel that this is something that could be neatly addressed now whilst in beta stage, as it'll be a lot harder to plug the leaks later.

See https://web.dev/first-party-cookie-recipes/#the-good-first-party-cookie-recipe

The 2nd parameter would be additionalOauth2ClientConfig?: OAuth2ClientConfig, allowing one to override the default OAuth config. This would also be used under the hood in other functions that use oauth2Client to provide additional customizability. E.g. signIn(provider: Provider) -> signIn(provider: ProviderId | Provider).

I think having a single function that constructs Provider objects over having multiple means better DX. Also, such a feature would be very cheap to implement if using a basic switch statement.

• Amazon
• Azure
• Discord
• Facebook
• GitHub
• GitLab
• Google
• Slack
• Twitter

How can you pass the callback redirection URL through the entire flow?

To clarify, I mean the URL that the callback handler redirects to - which is currently passed as the third arg to handleCallback.

I'd like the 'Referer' (or other arbitrary URL) to be passed from signin, all the way through the flow to the callback handler, so that the user ends up back on the same page after.

I've tried adding it to the callback URL, but some providers (eg. Google), don't allow this.

Closing. See #33.

I have been adding a few providers for this library. I am basically taking a few popular providers that are defined in NextAuth and porting (including testing if it works) it to Deno KV Auth.

Adding multiple providers becomes tedious when it is in 1 single file. I would propose:

• Creating a separate folder for the providers, making it easier to maintain them. Basically mimicking a similar structure like NextAuth
• Maybe make the demo.ts more generic, where you basically can import the OAuthProvider for easy testing. Right now I am changing demo.ts to locally test it and then revert the changes before I commit to the repo

If you want, I can make a PR with my suggested changes

The url in the README file (https://kv-oauth.deno.com) is not working for me. I guess it should be https://kv-oauth.deno.dev?

I raise this as it's been discussed elsewhere, and there is currently no explicit issue for it in this project.

There is a limitation in oauth2_client atm that prevents this: it doesn't expose the id_token, and there is no official way to
obtain that token from kv_oauth either. This can be worked around with a patch to oauth2_client (cmd-johnson/deno-oauth2-client#32) and use of the internal getTokens function.

Although experimental work is underway in oauth2_client to fully support the OIDC flow: https://github.com/cmd-johnson/deno-oauth2-client/tree/feature/oidc

See the following for guidance:

• https://github.com/denoland/deno_kv_oauth#adding-a-pre-configured-oauth-20-client for guidance.
• #110

Last week I was attempting to recreate the demo but with Auth0, all was good but I had to change this line to undefined as it seems getSessionId now returns undefined so this boolean checks fails.

const isSignedIn = sessionId !== null; // this may need to be changed to undefined

The providers are very repetitive atm, they don't validate the config, and attempt to get the env vars for id/secret even if those values are passed in the given additional config props, meaning that a consume of the lib must allow envs.

  return new OAuth2Client({
    clientId: Deno.env.get("GOOGLE_CLIENT_ID")!,
    clientSecret: Deno.env.get("GOOGLE_CLIENT_SECRET")!,
    authorizationEndpointUri: "https://accounts.google.com/o/oauth2/v2/auth",
    tokenUri: "https://oauth2.googleapis.com/token",
    ...additionalOAuth2ClientConfig,
  });

a simply function could standardize this, providing validation that all values are set as required and provide a place to improve/fix issues should they crop up (eg. fallback on env vars rather than requiring them).

a simple example of usage of such a fn:

const config = createOAuthConfig({
  name: "Google",
  authorizationEndpointUri: "https://accounts.google.com/o/oauth2/v2/auth",
  tokenUri: "https://oauth2.googleapis.com/token",
  ...additionalOAuth2ClientConfig,
});

At present a redirectUri is passed wholesale through the flow, and so must be configured as an absolute URL.
This often means you have to know your origin in advance or you have to configure your redirectUri and client at request time.

Example:

const redirectUri = new URL("/callback", req.url).href;
const client = createSomeOAuth2Client({ redirectUri });
return signIn(req, client);

As you are already passing the Request to the signIn/callbackHandler, these could resolve the URL instead...

const client = createSomeOAuth2Client({ redirectUri: "/callback" });
return signIn(req, client);