Nico Sabena nicosabena

## Startup-for-OIDC-HS256.cs
using System;
using Microsoft.AspNetCore.Authentication.Cookies;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Options;
using Microsoft.IdentityModel.Tokens;

## redirect-rule.js
function (user, context, callback) {

  // this rule requires the following configuration values:
  // CAPTCHA_SECRET: a 32 bytes string that will be the shared secret between
  //                 the rule and the webtask
  // AUTH0_DOMAIN: your auth0 domain (e.g. account.auth0.com)
  // CAPTCHA_REDIRECT: the URL for the webtask that will show and process CAPTCHA

  // Put a specific client ID if you dont want CAPTCHA for every client
  // if (context.clientID !== '[your client id]')

## azure-ad-groups.js
// This rule will get the groups for users coming from Azure AD
// Auth0 already has the option to do that, but it (currently) won't work
// if the user is coming from a different directory than the directory
// where the app is registered (this can happen with multi-tenant apps).
// It uses the access_token provided by Azure AD, so this needs
// the 'Open ID Connect' protocol selected in the Azure AD connection.
//
// After the rule runs, you will have the 'groups' property in the user
// that you can use to add custom claims to the id_token.
//

## azure-ad-groups-with-client-credentials.js
// This rule will get the groups for users coming from Azure AD
// Auth0 already has the option to do that, but it (currently) won't work
// if the user is coming from a different directory than the directory
// where the app is registered (this can happen with multi-tenant apps).
// This is a variation that gets an access token for Azure AD using the
// client-credential grants instead of using the access token given to the user.
// It's useful if a new access token from Azure AD is not obtained every time the rule runs,
// or if WS-Federation is used instead of OIDC.
//
// After the rule runs, you will have the 'groups' property in the user

## cookie-check-hosted-login-page.html
<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
  <title>Sign In with Auth0</title>
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
</head>
<body>
  <div id="nocookies" style="display:none">

## single-connection-hlp.html
<!DOCTYPE html>
<!--
  This hosted login page will go directly to a single upstream identity provider
  instead of showing Lock. It's a good choice for tenants that have only one
  connection enabled, or for individual applications with just one connection
  (in which case, the logic to decide to go directly to the idp needs to
  be changed, see below).
  It still keeps Lock if you do `prompt=login`, just in case.
-->

## delete_grants_after_password_change.js
async function (user, context, callback) {
  // this rule will run after a user changes their password and
  // delete, for the user, either:
  //   - all grants (for OIDC-Conformant usage)
  //   - all device credentials (for non OIDC-Conformant apps)
  // These actions will effectively invalidate all issued refresh tokens
  // on the next token request (be it an interactive login
  // or a refresh token flow).
  // It compares a user's last_password_rest property
  // against an "app_metadata.last_revoke" property used

## hosted login page with password and passwordless.html
<!--
This shows how you can have both a regular Lock or Passwordless Lock in the
hosted login page, and decide between the two based on some logic (e.g. like
based on the clientID, see the "usePasswordless" variable at the bottom of this code).

If your applications have both DB and passwordless connections
enabled, you could also present the option to the user (e.g. with a couple of buttons)
and then show the proper widget based on the user's selection.
-->

## Lock-with-extra-button.html
<!--
This example how you can add an extra button to Lock to directly
force an authentication with an enterprise connection (instead of relying
on Lock's home realm discovery with the email domain).

Warning: This is provided "as-is". It relies on Lock's current DOM structure, which
might change in future versions without previous warning and break this solution.

If you want buttons for your enterprise connections, a better idea is to
use the "New" Universal Login experience instead, which provides these

## restrict_scopes_in_rule.js
function (user, context, callback) {

  function getAllowedScopes(audience, clientID) {
    // openid profile email are OIDC scopes
    // real code would calculate allowedScopes based on
    // contextual information like audience,
    // context.clientID, context.clientName, context.connection, user
    let allowedScopes = ["openid","profile","email","read:timesheets"];
    return allowedScopes;
  }
	using System;
	using Microsoft.AspNetCore.Authentication.Cookies;
	using Microsoft.AspNetCore.Builder;
	using Microsoft.AspNetCore.Hosting;
	using Microsoft.AspNetCore.Http;
	using Microsoft.Extensions.Configuration;
	using Microsoft.Extensions.DependencyInjection;
	using Microsoft.Extensions.Logging;
	using Microsoft.Extensions.Options;
	using Microsoft.IdentityModel.Tokens;
	function (user, context, callback) {

	// this rule requires the following configuration values:
	// CAPTCHA_SECRET: a 32 bytes string that will be the shared secret between
	// the rule and the webtask
	// AUTH0_DOMAIN: your auth0 domain (e.g. account.auth0.com)
	// CAPTCHA_REDIRECT: the URL for the webtask that will show and process CAPTCHA

	// Put a specific client ID if you dont want CAPTCHA for every client
	// if (context.clientID !== '[your client id]')
	// This rule will get the groups for users coming from Azure AD
	// Auth0 already has the option to do that, but it (currently) won't work
	// if the user is coming from a different directory than the directory
	// where the app is registered (this can happen with multi-tenant apps).
	// It uses the access_token provided by Azure AD, so this needs
	// the 'Open ID Connect' protocol selected in the Azure AD connection.
	//
	// After the rule runs, you will have the 'groups' property in the user
	// that you can use to add custom claims to the id_token.
	//
	<!DOCTYPE html>
	<!--
	This hosted login page will go directly to a single upstream identity provider
	instead of showing Lock. It's a good choice for tenants that have only one
	connection enabled, or for individual applications with just one connection
	(in which case, the logic to decide to go directly to the idp needs to
	be changed, see below).
	It still keeps Lock if you do `prompt=login`, just in case.
	-->
	async function (user, context, callback) {
	// this rule will run after a user changes their password and
	// delete, for the user, either:
	// - all grants (for OIDC-Conformant usage)
	// - all device credentials (for non OIDC-Conformant apps)
	// These actions will effectively invalidate all issued refresh tokens
	// on the next token request (be it an interactive login
	// or a refresh token flow).
	// It compares a user's last_password_rest property
	// against an "app_metadata.last_revoke" property used
	<!--
	This shows how you can have both a regular Lock or Passwordless Lock in the
	hosted login page, and decide between the two based on some logic (e.g. like
	based on the clientID, see the "usePasswordless" variable at the bottom of this code).

	If your applications have both DB and passwordless connections
	enabled, you could also present the option to the user (e.g. with a couple of buttons)
	and then show the proper widget based on the user's selection.
	-->
	<!--
	This example how you can add an extra button to Lock to directly
	force an authentication with an enterprise connection (instead of relying
	on Lock's home realm discovery with the email domain).

	Warning: This is provided "as-is". It relies on Lock's current DOM structure, which
	might change in future versions without previous warning and break this solution.

	If you want buttons for your enterprise connections, a better idea is to
	use the "New" Universal Login experience instead, which provides these
	function (user, context, callback) {

	function getAllowedScopes(audience, clientID) {
	// openid profile email are OIDC scopes
	// real code would calculate allowedScopes based on
	// contextual information like audience,
	// context.clientID, context.clientName, context.connection, user
	let allowedScopes = ["openid","profile","email","read:timesheets"];
	return allowedScopes;
	}