Skipping the Consent Dialog

[panva]

Note

Author: @panva
Target version: ^9.0.0

Warning

• No guarantees this is bug-free, if you find a bug please comment on the discussion
• It is not recommended to have consent-free flows for the obvious issues this poses for native applications

Sometimes your use-case doesn't need a consent screen.

This might occur if the authorization server has only first-party clients configured. To achieve that you want to add the requested claims/scopes/resource scopes to the grant:

new Provider('/* your issuer identifier */', {
  async loadExistingGrant(ctx) {
    const grantId = ctx.oidc.result?.consent?.grantId 
      || ctx.oidc.session.grantIdFor(ctx.oidc.client.clientId);

    if (grantId) {
      // keep grant expiry aligned with session expiry
      // to prevent consent prompt being requested when grant expires
      const grant = await ctx.oidc.provider.Grant.find(grantId);

      // this aligns the Grant ttl with that of the current session
      // if the same Grant is used for multiple sessions, or is set
      // to never expire, you probably do not want this in your code
      if (ctx.oidc.account && grant.exp < ctx.oidc.session.exp) {
        grant.exp = ctx.oidc.session.exp;

        await grant.save();
      }

      return grant;
    }

    if (isFirstParty(ctx.oidc.client)) {
      const grant = new ctx.oidc.provider.Grant({
        clientId: ctx.oidc.client.clientId,
        accountId: ctx.oidc.session.accountId,
      });

      grant.addOIDCScope('openid email profile');
      grant.addOIDCClaims(['first_name']);
      grant.addResourceScope('urn:example:resource-indicator', 'api:read api:write');
      await grant.save();
      return grant;
    }

    return undefined;
  }
});

This will get you as far as not asking for any consent unless the application is a native application (e.g. iOS, Android, CLI, Device Flow). It is recommended to still show a consent screen to those with the application details to those since they are public clients and their redirect_uri ownership can rarely be validated.

[itsMarydan]

I have not been able to get this working yet I get this error
Cannot read properties of undefined (reading 'getOIDCScopeFiltered') at interactions

[panva]

I cannot reproduce your issue. Taking the example above with isFirstParty just being a true-returning function works as expected.

[Hieung28]

@panva How can i disable consent form if my application is native

[panva]

By specifying your own interactions.policy that doesn't include the native_client_prompt Check.

[pavelsvagr]

@panva Thanks for the tutorial — it works well for the general use case of base scopes. However, for first-party applications, it's also important to be able to skip the consent screen when requesting refresh tokens.

Currently, the implementation in check_scope automatically filters out the offline_access scope if the request doesn't include prompt=consent. This behavior contradicts the intent of the tutorial — as a first-party application, I don’t want to require prompt=consent just to obtain a refresh token.

Moreover, this logic makes it impossible for developers to even detect that the offline_access scope was requested, as it's silently removed.

I’d prefer a solution where the provider doesn’t modify the originally requested scopes, and instead works it out it's own way at the end when creating the grants. This would give developers access to the full original request and they can make an informed decision within the issueRefreshToken function about whether a refresh token should be issued or not. What do you think?

[panva]

when requesting refresh tokens

You're equating OAuth 2.0 refresh token issuance with the concept of OpenID Connect's offline access, which the scope offline_access is for.

issueRefreshToken doesn't have the context necessary to implement the offline_access conditions and requirements as per ¶ 11. Offline Access which is why the offline_access scope is pulled from the request as per the OIDC requirements.

The defaults are set up for the offline access concept but with the helpers available you're free to set your AS up to issue refresh tokens just by looking at the client's allowed grants.

[pavelsvagr]

I agree with your points, but the OIDC specification explicitly states:

When offline access is requested, a prompt parameter value of consent MUST be used unless other conditions for processing the request permitting offline access to the requested resources are in place.

The library currently ignores the second part of this requirement. I’m fine with using custom logic in issueRefreshToken, but I disagree with the library removing information about which scopes were originally requested.

If my custom logic depends on whether the offline_access scope was requested — regardless of whether prompt=consent was used — I should still have access to that information. Currently, I’m forced to include prompt=consent, which automatically triggers the consent screen, just to retain visibility of that scope.

[jim-y]

For others.. in my case it wasn't enough to only tamper the loadExistingGrant function, because the consent prompt can be still triggered by other conditions. Like if your flow involves requesting a refresh_token you would you the offline_access scope alongside the prompt=consent property and the prompt=consent would still trigger the need to show the consent screen. So here's what I did:

1. extended the client metadata with an additional field "trusted"
2. created a custom loadExistingGrant function as mentioned above by @panva
3. overrode the basePolicies for consent as

import { Provider, interactionPolicy } from 'oidc-provider';
import type { Configuration, Client } from 'oidc-provider';
const basePolicy = interactionPolicy.base();
const Check = interactionPolicy.Check;
const consentPrompt = basePolicy.get('consent');
const isTrusted = (client?: Client) => client && client['trusted'] != null && client['trusted'] === true;

if (consentPrompt) {
	const consentCheck = consentPrompt.checks.get('consent_prompt');
	if (consentCheck) {
		consentCheck.check = (ctx) => {
			const { oidc } = ctx;
			const client = oidc.client;

			if (!oidc.prompts.has('consent')) {
				return Check.NO_NEED_TO_PROMPT;
			}

			if ((!isTrusted(client) && !oidc.result?.consent) || oidc.promptPending('consent')) {
				return Check.REQUEST_PROMPT;
			}

			return Check.NO_NEED_TO_PROMPT;
		};
	}
	const nativeClientCheck = consentPrompt.checks.get('native_client_prompt');
	if (nativeClientCheck) {
		nativeClientCheck.check = (ctx) => {
			const { oidc } = ctx;
			const client = oidc.client;

			if (isTrusted(client)) {
				return Check.NO_NEED_TO_PROMPT;
			}

			// Original logic for non-trusted clients
			if (
				client &&
				client.applicationType === 'native' &&
				oidc.params &&
				oidc.params.response_type !== 'none' &&
				!oidc.result?.consent
			) {
				return Check.REQUEST_PROMPT;
			}

			return Check.NO_NEED_TO_PROMPT;
		};
	}
}

note: the logic might be improved, haven't run into edge-cases yet.

Reasoning:

as previous conversations in this thread mentioned, asking for a refresh_token is done by conforming to 3 conditions:

1. the client model has the refresh_token flow enabled. grant_types: ['refresh_token']
2. the client request uses the offline_access scope value
3. the client request uses the prompt=consent property

Rewriting the loadExistingGrant function to automatically grant every available scope for a trusted client only solves that the consent prompt won't be showed because a certain openid scope is missing. We grant every scope -> no scope is missing -> no need to show the consent.

However, using the prompt=consent will still trigger the need to show the consent screen because the original request explicitly used prompt=consent. To solve this we have to edit the base interaction policy for -> consentPrompt.checks.get('consent_prompt');

If your client is also a native client then you also have to edit the -> consentPrompt.checks.get('native_client_prompt');

After all these, you can finally skip the consent screen for trusted (first-party) clients.

I hope this helps someone.