okta signin widget
7.25.1
Le widget de connexion OKTA est un widget JavaScript qui offre une expérience de connexion entièrement en vedette et personnalisable qui peut être utilisée pour authentifier et enregistrer les utilisateurs dans les applications Web et mobiles.
Le widget est utilisé sur la page Signin par défaut d'Okta pour démarrer une session OKTA SSO et définir le cookie de session OKTA dans le navigateur Web. Il peut également effectuer un flux OIDC pour intégrer facilement vos applications Web ou mobiles dans la plate-forme OKTA.
Une page Signin Hosted personnalisée peut être configurée pour utiliser le nom de domaine et l'image de marque de votre organisation.
Le widget peut également être intégré directement dans les applications Web ou mobiles de votre organisation pour une expérience utilisateur transparente.
Voir le guide d'utilisation pour plus d'informations sur la façon de commencer à utiliser le widget de connexion.
yarn linkLe moteur d'identité OKTA (OIE) est un service de plate-forme qui permet aux entreprises de créer des expériences d'accès plus flexibles adaptées à leurs besoins organisationnels. Le widget de connexion OKTA prend en charge l'OIE dans tous les scénarios d'utilisation.
Remarque : Sauf indication contraire, ce ReadMe suppose que vous utilisez Identity Engine. Les informations sur l'utilisation du widget avec le moteur classique se trouvent dans ce document
Le widget de connexion est autonome et ne nécessite aucun autre cadre lors de l'exécution. Cependant, il peut y avoir certaines fonctionnalités dont votre application a besoin telle que le stockage, le renouvellement ou la validation des jetons, que le widget ne fournit pas.
Ces SDK sont entièrement compatibles avec le widget de connexion OKTA et fournissent des utilitaires pour aider à intégrer l'authentification OKTA de bout en bout dans votre propre application.
Les applications d'échantillons complètes montrent l'utilisation du widget de connexion OKTA dans les scénarios hébergés et intégrés d'Okta.
Il existe plusieurs façons d'utiliser le widget de connexion OKTA:
Okta fournit une page de connexion par défaut pour votre organisation, hébergée à l'URL OKTA de votre organisation.
OKTA prend en charge une option pour créer un domaine personnalisé avec une page de connexion homogène homogène OKTA.
Vous pouvez intégrer le widget directement dans votre application.
Okta fournit une page de connexion, disponible sur l'URL de votre organisation, qui permet à l'utilisateur de terminer l'intégralité du flux d'autorisation, de démarrer une session SSO (connexion unique) et de définir le cookie de session OKTA dans le navigateur Web. Vous pouvez personnaliser cette page avec une image d'arrière-plan et un logo. Par défaut, la signature sur cette page redirige l'utilisateur vers le tableau de bord de l'utilisateur OKTA.
La page de connexion par défaut d'Okta peut également authentifier un utilisateur dans une application OIDC. Votre application peut rediriger vers une page de connexion pour effectuer le flux d'authentification, après quoi Okta redirige l'utilisateur vers le rappel de l'application. Okta fournit des SDK dans de nombreuses langues pour aider à construire l'URL de redirection et à gérer le rappel de connexion dans le cadre du flux hébergé.
Okta fournit plusieurs échantillons complets qui montrent comment utiliser le flux hébergé Okta.
Okta fournit également une page de connexion hébergée qui peut être personnalisée afin qu'elle soit disponible dans un domaine personnalisé qui est un sous-domaine du domaine de niveau supérieur de votre entreprise. Bien que la page soit hébergée par Okta, vous pouvez personnaliser le modèle de cette page de nombreuses manières puissantes.
En ce qui concerne votre application, le widget personnalisé se comporte de la même manière que le widget hébergé par défaut OKTA et vous pouvez utiliser le même flux hébergé.
Remarque: il y aura un objet de configuration sur la page qui contient toutes les valeurs requises et les fonctionnalités activées. Vous n'aurez probablement pas besoin de modifier cet objet. Si vous constatez que vous devez modifier cette configuration, veillez à ne pas écraser ou supprimer les valeurs requises.
Pour une expérience complètement transparente qui permet le plus haut niveau de personnalisation, vous pouvez intégrer le widget de connexion directement dans votre application. Cela permet une utilisation complète de la configuration et de l'API du widget.
L'utilisation d'un widget embarqué, les applications Web côté client et natives peuvent éviter la redirection aller-retour du flux hébergé dans de nombreux cas. Voir showsignin.
Les applications Web côté serveur recevront le côté du serveur de jetons OAuth, ils doivent donc gérer un rappel de redirection . Ces applications doivent utiliser ShowsignInAndRedirect.
Vous pouvez intégrer le widget de connexion dans votre application en y compris une balise de script qui tire le widget de l'OKTA CDN ou en regroupant le module NPM dans votre application.
Le chargement de nos actifs directement à partir du CDN est un bon choix si vous voulez un moyen facile de démarrer avec le widget, n'a pas déjà de processus de construction existant qui exploite le NPM ou le fil pour les dépendances externes, ou toute autre raison où vous ne faites pas T Je souhaite regrouper le widget de connexion dans votre application.
Le bundle standard ( okta-sign-in.min.js ) comprend la prise en charge du moteur classique et du moteur d'identité. Il comprend également un polyfill pour garantir la compatibilité avec des navigateurs plus anciens tels que IE11. Si votre application n'a pas besoin de prendre en charge IE11, vous pouvez plutôt inclure le bundle no-polyfill pour réduire le temps de chargement pour les nouveaux utilisateurs. Le faisceau polyfill autonome peut être inclus conditionnellement sur les pages pour ajouter la prise en charge des navigateurs plus anciens uniquement lorsque cela est nécessaire.
Si votre organisation est mise à niveau vers Identity Engine, le petit pack oie peut être utilisé.
| Paquet | Nom de fichier | Env. Taille | Moteur classique | Moteur d'identité | Polyfillage | Notes |
|---|---|---|---|---|---|---|
| standard | Okta-Sign-in.min.js | 1,7 Mb | ✅ | ✅ | ✅ | Pack standard qui comprend tout |
| sans polyvale | Okta-Sign-in.no-Polyfill.min.js | 1,7 Mb | ✅ | ✅ | Fondeau standard sans polyfill | |
| oisonne | Okta-Sign-in.oie.min.js | 1,3 Mb | ✅ | Poule plus petit pour les orgs compatibles OIE | ||
| classique | Okta-Sign-in.classic.min.js | 1,1 Mb | ✅ | Boule d'attente plus petit pour moteur classique uniquement | ||
| polyfillage | Okta-Sign-in.polyfill.min.js | 108KB | ✅ | Fondeau en polyflux autonome. Peut être utilisé avec un pack de widget qui n'inclut pas le polyfill. |
Pour intégrer le widget de connexion via CDN, incluez des liens vers les fichiers JS et CSS dans votre HTML:
<!-- Latest CDN production Javascript and CSS -->
< script src =" https://global.oktacdn.com/okta-signin-widget/7.25.1/js/okta-sign-in.min.js " type =" text/javascript " integrity =" sha384-8QHSy1n8imbyR7imair5z4njOEYiZZk5gqBOJYbbUN3W6HQwW3PZ9lYQiybespeW " crossorigin =" anonymous " > </ script >
< link href =" https://global.oktacdn.com/okta-signin-widget/7.25.1/css/okta-sign-in.min.css " type =" text/css " rel =" stylesheet " integrity =" sha384-63aTBe2wMqzMRsDHNmlF/FreSWmf3p08BhUDoPlzVf3d+stbkfWtqmdyJ4He5m3m " crossorigin =" anonymous " />Remarque: Les URL CDN contiennent un numéro de version. Ce numéro doit être le même pour le fichier JavaScript et le fichier CSS et faire correspondre une version sur la page des versions. Nous vous recommandons d'utiliser la dernière version du widget.
Lorsque vous utilisez l'un des packs sans le polyfill inclus, vous voudrez peut-être charger conditionnellement le faisceau de polyfill autonome. Le polyfill doit être chargé avant le pack de widgets:
<!-- Polyfill for older browsers -->
< script src =" https://global.oktacdn.com/okta-signin-widget/7.25.1/js/okta-sign-in.polyfill.min.js " type =" text/javascript " integrity =" sha384-QzQIGwIndxyBdHRQOwgjmQJLod6LRMchZyYg7RUq8FUECvPvreqauQhkU2FF9EGD " crossorigin =" anonymous " > </ script >
<!-- Widget bundle for Okta Identity Engine -->
< script src =" https://global.oktacdn.com/okta-signin-widget/7.25.1/js/okta-sign-in.oie.min.js " type =" text/javascript " integrity =" sha384-T4d68QBaFQ/b3kDy8qubuXDALwWgBRfP0JsfZsYRzZNlIXflVE2svwIHrPaivLyd " crossorigin =" anonymous " > </ script >
<!-- CSS for widget -->
< link href =" https://global.oktacdn.com/okta-signin-widget/7.25.1/css/okta-sign-in.min.css " type =" text/css " rel =" stylesheet " integrity =" sha384-63aTBe2wMqzMRsDHNmlF/FreSWmf3p08BhUDoPlzVf3d+stbkfWtqmdyJ4He5m3m " crossorigin =" anonymous " />L'utilisation de notre module NPM est un bon choix si:
Pour installer @ OKTA / OKTA-SIGNIN-WIDGET:
# Run this command in your project root folder
# yarn
yarn add @okta/okta-signin-widget
# npm
npm install @okta/okta-signin-widget --save Cela installe la dernière version du widget de connexion dans le répertoire node_modules de votre projet.
Remarque: Si vous utilisez TypeScript, vous devrez activer les importations synthétiques dans votre tsconfig.json .
{
...
"compilerOptions" : {
"allowSyntheticDefaultImports" : true ,
...
}
} Les projets angulaires (TypeScript) nécessitent une configuration similaire, également dans votre tsconfig.json
{
...
"angularCompilerOptions" : {
"allowSyntheticDefaultImports" : true ,
...
}
} Les fichiers et actifs source du widget sont installés sur node_modules/@okta/okta-signin-widget/dist , et ont cette structure de répertoire:
node_modules/@okta/okta-signin-widget/dist/
├── css/
│ │ # Main CSS file for widget styles
│ └── okta-sign-in.min.css
│
│ # Base font and image files that are used in rendering the widget
├── font/
│
├── img/
│
├── js/
│ │ # CDN JS file that exports the OktaSignIn object in UMD format. This is
│ │ # packaged with everything needed to run the widget, including 3rd party
│ │ # vendor files and polyfills.
│ ├── okta-sign-in.min.js
| |
│ │ # CDN JS file bundled without polyfills.
│ ├── okta-sign-in.no-polyfill.min.js
│ │
│ │ # Development version of okta-sign-in.min.js. Equipped with helpful
│ │ # console warning messages for common configuration errors.
│ └── okta-sign-in.js
│
│ # Localized strings that are used to display all text and labels in the
│ # widget. Three output formats are included - json and properties
├── labels/
│
│ # Sass files that are used to generate the widget css. If you are already
│ # using Sass in your project, you can include these helper files to make
│ # generating your custom theme easier
└── sass/Après l'installation:
Copiez les actifs dans un dossier qui sera distribué à votre site hébergé publiquement. Les dossiers que vous devrez copier sont css , font , img , js et labels .
Au lieu de copier le répertoire js et de l'inclure dans votre page en tant que global, vous pouvez nécessiter le widget de connexion dans votre build si vous utilisez WebPack, Browserify ou un autre système de regroupement de modules qui comprend le format node_modules .
// Load the Sign-In Widget module
var OktaSignIn = require ( '@okta/okta-signin-widget' ) ;
// Use OktaSignIn
var signIn = new OktaSignIn ( /* configOptions */ ) ;Les cartes source sont fournies en tant que fichier .map externe. Si vous utilisez WebPack, ceux-ci peuvent être chargés à l'aide du plugin Source-Map-chargedeur.
Si vous souhaitez inclure des styles de widget dans un bundle à l'aide de style de style ou de mini-CSS-Extract-Plugin, utilisez l'importation suivante:
import '@okta/okta-signin-widget/css/okta-sign-in.min.css' ; Remarque: Si vous utilisez Browserify pour regrouper votre application, vous devrez utiliser l'option --noparse :
browserify main.js
--noparse= $PWD /node_modules/@okta/okta-signin-widget/dist/js-okta-sign-in.entry.js
--outfile=bundle.jsAssurez-vous d'inclure des polyfills ES6 avec votre bundler si vous devez prendre en charge IE11. Le widget fournit tous les polyfills nécessaires via une exportation:
const polyfill = require('@okta/okta-signin-widget/polyfill');
ou
import polyfill from '@okta/okta-signin-widget/polyfill';
Ces exemples simples devraient vous aider à démarrer avec l'utilisation du widget de connexion. Pour des solutions complètes de bout en bout, consultez nos exemples d'applications.
Une seule application de page (SPA) s'exécute complètement dans le navigateur. Les applications SPA s'authentifient à l'aide de flux côté client et stockent les jetons OAuth dans le stockage basé sur le navigateur.
Remarque: Voir la configuration pour plus d'informations sur ces valeurs de configuration
var signIn = new OktaSignIn (
{
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : '{{clientId of your OIDC app}}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
}
) ;
signIn . showSignIn ( {
// Assumes there is an empty element on the page with an id of 'osw-container'
el : '#osw-container'
} ) . then ( function ( res ) {
// Most flows will not require any redirection. In these cases, tokens will be returned directly.
// res.tokens is an object
oktaSignIn . authClient . handleLoginRedirect ( res . tokens ) ;
} ) . catch ( function ( error ) {
// This function is invoked with errors the widget cannot recover from:
// Known errors: CONFIG_ERROR, UNSUPPORTED_BROWSER_ERROR
} ) ; Une application Web s'exécute principalement sur le serveur. Le widget, qui exécute côté client, sera intégré à une page HTML qui comprend un bloc de script qui configure et rend le widget. Les jetons OAuth seront reçus côté serveur sur le rappel de redirection de connexion de l'application.
Remarque: Voir la configuration pour plus d'informations sur ces valeurs de configuration
var signIn = new OktaSignIn (
{
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : '{{clientId of your OIDC app}}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
state : '{{state passed from backend}}' , // state can be any string, it will be passed on redirect callback
codeChallenge : '{{PKCE code challenge from backend}}' , // PKCE is required for interaction code flow
}
) ;
// When the authorization flow is complete there will be a redirect to Okta.
// Okta's servers will process the information and then redirect back to your application's `redirectUri`
// If successful, an authorization code will exist in the URL as the "code" query parameter
// If unsuccesful, there will be an "error" query parameter in the URL
signIn . showSignInAndRedirect ( {
// Assumes there is an empty element on the page with an id of 'osw-container'
el : '#osw-container'
} ) . catch ( function ( error ) {
// This function is invoked with errors the widget cannot recover from:
// Known errors: CONFIG_ERROR, UNSUPPORTED_BROWSER_ERROR
} ) ; En plus du flux d'authentification par défaut, le widget prend en charge plusieurs flux prédéfinis, qui vous permettent de fournir des pages HTML à usage unique pour plusieurs cas d'utilisation courants.
Par défaut, le widget de connexion OKTA procédera à un flux de courant ou démarrera un nouveau flux d'authentification. L'option flow permet de bootstrap le widget dans une vue spécifique telle que le registre, le déverrouillage ou la réinitialisation du mot de passe. Flux pris en charge:
Remarque: un flux particulier ne peut fonctionner que si l'administrateur a configuré l'organisation pour permettre les opérations requises (exemple: si l'inscription du profil (inscription utilisateur) dans la console d'administration n'est pas activée, l'amorçage du widget avec
flow: 'signup'entraîner une erreur)
// login.html
new OktaSignIn ( {
flow : 'login'
} ) ;
// signup.html
new OktaSignIn ( {
flow : 'signup'
} ) ;
// reset_password.html
new OktaSignIn ( {
flow : 'resetPassword'
} ) ;
// unlock_account.html
new OktaSignIn ( {
flow : 'unlockAccount'
} ) ; Un rappel de redirection se produit lorsque votre application est rechargée dans le navigateur dans le cadre d'un flux. Au cours d'un rappel de redirection, l'application est chargée sur un chemin d'établissement d'URL spécifique que vous avez défini dans la configuration de votre application OKTA. La plupart des rappels ne peuvent être gérés qu'une seule fois et produiront une erreur s'il y a une tentative de le gérer deux fois. En règle générale, l'application se redirige vers un chemin d'URL bien connu ou précédemment enregistré après que la logique de rappel a été gérée pour éviter les erreurs sur le rechargement de la page.
Remarque: La plupart des applications doivent être prêtes à gérer un ou plusieurs rappels de redirection. Selon la façon dont la stratégie de connexion de l'application est configurée, certaines applications SPA peuvent être en mesure de recevoir des jetons sans aucune redirection. Cependant, la logique devra être ajoutée si la politique comprend la connexion avec un fournisseur social / IDP ou permet une authentification ou une récupération de compte à l'aide de la vérification par e-mail.
Le rappel OAuth est la dernière étape du flux de code d'interaction. Sur une authentification réussie, le navigateur est redirigé vers Okta avec des informations pour commencer une nouvelle session. Les serveurs d'Okta traitent les informations, puis redirigent vers redirectUri de votre application. En cas de succès, un code d'interaction est présent dans l'URL en tant que paramètre de requête interaction_code . En cas d'échec, il y a une error et des paramètres de requête error_description dans l'URL. Qu'il s'agisse de réussir ou non, le paramètre state , qui a été initialement transmis au widget par votre demande, sera également retourné sur la redirection. Cela peut être utilisé par les applications Web côté serveur pour correspondre au rappel avec la bonne session utilisateur.
Toutes les applications Web géreront un rappel OAuth . Pour les applications SPA, dans de nombreux cas, la politique de connexion ne nécessitera pas de redirection et ces applications peuvent recevoir des jetons directement à partir de Showsignin. Cependant, si la politique de connexion nécessite une redirection pour une raison quelconque (comme l'intégration avec un fournisseur social / IDP), les applications SPA devront gérer un rappel OAuth. Pour cette raison, nous recommandons que toutes les applications SPA soient prêtes à gérer un rappel OAuth .
Remarque: le widget ne gère pas directement un rappel OAuth. Les applications Web côté serveur peuvent utiliser l'un de nos SDK pour aider à gérer le rappel. Les applications SPA peuvent utiliser le SDK Okta-Auth-JS, qui est incluse avec le widget de connexion en tant que propriété
authClient.
Une application SPA peut gérer le côté client OAuth à l'aide de l' authClient intégré:
// https://myapp.mycompany.com/login/callback?interaction_code=ABC&state=XYZ
if ( signIn . authClient . isLoginRedirect ( ) ) {
await signIn . authClient . handleLoginRedirect ( ) ;
} Après avoir signé avec un IDP tiers, l'utilisateur est redirigé vers le redirectUri de l'application. Si aucune autre entrée n'est nécessaire de l'utilisateur, ce sera un rappel OAuth contenant un paramètre interaction_code . Si une entrée supplémentaire est requise, le rappel contiendra un paramètre error avec la valeur interaction_required . Dans ce cas, le widget de connexion doit être chargé à nouveau afin que le débit puisse se poursuivre.
Les applications Web et SPA côté serveur doivent rechercher le paramètre de requête error et, si la valeur est interaction_required , ils devraient rendre le widget à nouveau en utilisant la même configuration que le premier rendu. Le paramètre state sera également transmis sur le rappel qui peut être utilisé pour correspondre à la demande avec la session d'application de l'utilisateur. Le widget procédera automatiquement à la transaction.
Votre application devra implémenter un rappel de vérification par e-mail si votre stratégie de connexion utilise le lien magique par e-mail / OTP. Après que l'utilisateur a cliqué sur le lien dans un e-mail, il est redirigé vers l' email verify callback URI . Les paramètres de requête transmis à l'application incluent state et otp . Comme pour le rappel social / IDP, le widget doit être rendu à nouveau en utilisant la même configuration. De plus, l' otp doit être transmis au constructeur du widget.
Remarque: Voir la configuration pour plus d'informations sur ces valeurs de configuration
var signIn = new OktaSignIn (
{
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : '{{clientId of your OIDC app}}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
state : '{{state from URL}}' ,
otp : '{{otp from URL}}'
}
) ; Crée une nouvelle instance du widget de connexion avec les options fournies.
Pour les applications utilisant un widget hébergé OKTA personnalisé, il y aura un objet de configuration sur la page qui contient toutes les valeurs requises. Vous n'aurez probablement pas besoin de modifier cet objet.
Pour les applications utilisant un widget intégré, vous devrez fournir une configuration OIDC:
Remarque: Voir la configuration pour plus d'informations sur ces valeurs de configuration
var signIn = new OktaSignIn (
{
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : '{{clientId of your OIDC app}}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
}
) ;Rend le widget au Dom. Sur le succès, la promesse résout. Sur l'erreur, la promesse rejette. Si la politique de connexion nécessite une redirection vers OKTA ou un autre fournisseur d'identité (IDP), le navigateur sera redirigé et la promesse ne résoudra pas. Les réponses et les erreurs sont les mêmes que celles du rendu.
Remarque : Il s'agit du moyen recommandé de rendre le widget pour les applications SPA. Les applications Web côté serveur doivent plutôt utiliser la méthode ShowsignInAndRedirect.
showSignIn accepte les mêmes options que le constructeur du widget. Les options transmises à la méthode remplaceront les options du constructeur.
Remarque: Voir la configuration pour plus d'informations sur ces valeurs de configuration
var signIn = new OktaSignIn ( {
issuer : 'https://{yourOktaDomain}/oauth2/default'
clientId : '{{clientId of your OIDC app}}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
} ) ;
oktaSignIn . showSignIn ( {
// Assumes there is an empty element on the page with an id of ‘osw-container’
el : ‘ # osw - container’ ,
} ) . then ( response => {
oktaSignIn . authClient . handleLoginRedirect ( res . tokens ) ;
} ) . catch ( function ( error ) {
// This function is invoked with errors the widget cannot recover from:
// Known errors: CONFIG_ERROR, UNSUPPORTED_BROWSER_ERROR
console . log ( 'login error' , error ) ;
} ) ; Rend le widget au Dom. Sur une authentification réussie, le navigateur sera redirigé vers Okta avec des informations pour commencer une nouvelle session. Les serveurs d'Okta traiteront les informations, puis redirigeront vers redirectUri de votre application. En cas de succès, un code d'interaction existera dans l'URL en tant que paramètre de requête interaction_code . En cas d'échec, il y aura des paramètres de requête error and error_description dans l'URL. Quoi qu'il en soit, le paramètre state qui a été transmis au widget sera également retourné sur redirection. Cela peut être utilisé par votre application Web côté serveur pour correspondre au rappel avec la bonne session utilisateur.
showSignInAndRedirect accepte les mêmes options que le constructeur du widget. Les options transmises à la méthode remplaceront les options du constructeur.
Remarque: Voir la configuration pour plus d'informations sur ces valeurs de configuration
var signIn = new OktaSignIn ( {
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : '{{clientId of your OIDC app}}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
state : '{{state passed from backend}}' , // state can be any string, it will be passed on redirect callback
codeChallenge : '{{PKCE code challenge from backend}}' , // PKCE is required for interaction code flow
} ) ;
signIn . showSignInAndRedirect ( {
// Assumes there is an empty element on the page with an id of 'osw-container'
el : '#osw-container'
} ) . catch ( function ( error ) {
// This function is invoked with errors the widget cannot recover from:
// Known errors: CONFIG_ERROR, UNSUPPORTED_BROWSER_ERROR
} ) ;Cachez le widget, mais gardez le widget dans le DOM.
signIn . hide ( ) ;Affichez le widget si caché.
signIn . show ( ) ;Retirez entièrement le widget du Dom.
signIn . remove ( ) ;Abonnez-vous à un événement publié par le widget.
event - Événement pour s'abonner àcallback - fonction à appeler lorsque l'événement est déclenché // Handle a 'ready' event using an onReady callback
signIn . on ( 'ready' , onReady ) ;Se désinscrire des événements du widget. Si aucun rappel n'est fourni, désabonnez tous les auditeurs de l'événement.
event - événement facultatif pour se désabonner decallback - rappel facultatif qui a été utilisé pour s'abonner à l'événement // Unsubscribe all listeners from all events
signIn . off ( ) ;
// Unsubscribe all listeners that have been registered to the 'ready' event
signIn . off ( 'ready' ) ;
// Unsubscribe the onReady listener from the 'ready' event
signIn . off ( 'ready' , onReady ) ;Fournit accès à l'objet sous-jacent [@ OKTA / OKTA-AUTH-JS] [] utilisé par le widget de connexion. Toutes les méthodes sont documentées dans la référence de l'API.
L' authClient est configuré en utilisant des valeurs transmises au widget, telles que clientId , issuer , redirectUri , state et scopes . Les options qui ne sont pas directement prises en charge par le widget peuvent être transmises à AuthJS à l'aide de l'objet authParams .
L' authClient peut également être créé et configuré à l'extérieur du widget et transmis au widget comme l'option authClient . Si une option authClient est passée, authParams sera ignoré.
Remarque: Voir la configuration pour plus d'informations sur ces valeurs de configuration
var authClient = new OktaAuth ( {
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : '{yourClientId}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
} ) ;
var config = {
baseUrl : 'https://{yourOktaDomain}' ,
authClient : authClient ,
} ;
var signIn = new OktaSignIn ( config ) ;
// signIn.authClient === authClient Si aucune option authClient n'est définie, une instance sera créée à l'aide des options transmises au widget et authParams :
Remarque : Lorsque vous utilisez l'option de configuration
authClient, assurez-vous d'installer et d'utiliser la même version de@okta/okta-auth-jsque celle utilisée par le widget installé. Cette version se trouve dans le fichierpackage.jsondu widget installé.
var config = {
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : '{yourClientId}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
authParams : {
ignoreSignature : true
}
} ;
var signIn = new OktaSignIn ( config ) ;
// signIn.authClient.options.clientId === '{yourClientId}'
// signIn.authClient.options.ignoreSignature === true'Ajoute une fonction de crochet asynchrone qui s'exécutera avant qu'une vue ne soit rendue.
Remarque: Voir la configuration pour plus d'informations sur ces valeurs de configuration
var config = {
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : '{yourClientId}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
} ;
var signIn = new OktaSignIn ( config ) ;
signIn . before ( 'success-redirect' , async ( ) => {
// custom logic can go here. when the function resolves, execution will continue.
} ) ;Remarque : cette fonction n'est prise en charge que lors de l'utilisation du moteur d'identité OKTA
Ajoute une fonction de crochet asynchrone qui s'exécutera après une vue rendue.
Remarque: Voir la configuration pour plus d'informations sur ces valeurs de configuration
var config = {
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : '{yourClientId}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
} ;
var signIn = new OktaSignIn ( config ) ;
signIn . after ( 'identify' , async ( ) => {
// custom logic can go here. when the function resolves, execution will continue.
} ) ; Si vous utilisez la page Signin hébergée par défaut OKTA, toute la configuration est gérée via la section Customization de l'interface utilisateur d'administration.
Si vous utilisez la page Signin Hosted Hosted personnalisée, un objet de configuration est inclus sur la page qui contient toutes les valeurs nécessaires. Vous n'aurez probablement pas besoin de modifier cet objet, mais vous pouvez utiliser cet objet comme point de départ et ajouter des personnalisations supplémentaires.
Pour les widgets intégrés, vous devez définir l' issuer , clientId et redirectUri . Par défaut, le widget s'exécutera sur le moteur d'identité à l'aide du flux de code d'interaction. Le widget peut également s'exécuter contre le moteur classique en définissant l'option UseClassiceNngine sur true . (Voir ce document pour plus de détails sur la course dans un moteur classique.
Tous les widgets intégrés doivent définir ces options de base: issuer , clientId et redirectUri .
Remarque : les widgets hébergés par OKTA ne doivent pas définir ces valeurs.
L'URL du serveur d'autorisation qui émettra des jetons OAuth à votre application.
Remarque :
https://{yourOktaDomain}peut être n'importe quelle organisation OKTA. Consultez notre Guide de développeur pour obtenir de l'aide pour trouver votre domaine Okta.
Configuration de base à l'aide du serveur d'autorisation personnalisé "par défaut":
var config = {
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : '{{clientId of your OIDC app}}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
}Un autre serveur d'autorisation personnalisé peut être spécifié:
var config = {
issuer : 'https://{yourOktaDomain}/oauth2/custom' ,
clientId : '{{clientId of your OIDC app}}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
} Certaines applications, telles que celles qui ont besoin d'accès à l'API utilisateur OKTA, voudront utiliser le serveur d'autorisation d'organisation OKTA comme émetteur. Dans ce cas, l' issuer doit correspondre à votre domaine Okta:
var config = {
issuer : 'https://{yourOktaDomain}' ,
clientId : '{{clientId of your OIDC app}}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
}Remarque : Le serveur d'autorisation d'organisation OKTA est uniquement destiné à l'accès à l'API d'utilisateur OKTA et ne prend pas en charge toutes les fonctionnalités du serveur d'autorisation personnalisé standard, telles que les portées personnalisées sur les jetons d'accès. Il est généralement recommandé d'utiliser un serveur d'autorisation personnalisé pour sécuriser l'accès aux ressources de votre organisation.
Remarque : Cette valeur de configuration se trouve dans l'interface utilisateur d'administration OKTA. Consultez notre Guide de développeur pour obtenir de l'aide pour trouver le clientID de votre application
ID client de l'application.
Remarque : Cette valeur de configuration peut être trouvée dans l'interface utilisateur d'administration OKTA dans les "paramètres généraux" de l'application "
L'URI à utiliser pour le rappel OAuth.
Par défaut est false . Par défaut, le widget utilisera le flux de code d'interaction sur le moteur d'identité. La définition de l'option useClassicEngine sur true fera que le widget s'exécutera à la place contre le moteur classique. (Voir ce document pour plus de détails sur la configuration d'un widget fonctionnant dans un moteur classique).
Remarque : Cette option, ainsi que la prise en charge du moteur classique, seront supprimées dans une future version de widget. Tous les clients sont encouragés à migrer du moteur classique vers le moteur d'identité. Visitez la migration vers l'OIE pour plus de détails sur la migration vers le moteur d'identité.
Le défi du code PKCE. Les applications SPA n'auront pas besoin de cette option, car le widget gérera l'intégralité de la transaction. Les applications Web devraient générer leur propre défi de code et secret de code. Le défi du code est réalisé au widget et le secret de code est maintenu côté serveur pour obtenir des jetons sur le rappel de connexion Redirect.
Remarque : consultez nos exemples d'applications pour des exemples de travail complets de flux de code d'interaction à l'aide de PKCE
Une valeur fournie par l'application qui sera renvoyée sous forme de paramètre de requête pendant le rappel de connexion Redirection ou de vérification par e-mail. Si aucune valeur n'est définie, une valeur aléatoire sera créée. Lors du traitement d'un rappel de vérification par e-mail, la valeur de state du paramètre de requête doit être transmise au widget en tant qu'option de configuration (avec OTP). Cela garantira que le widget peut charger et reprendre la transaction actuelle.
Lors du traitement d'un rappel de vérification par e-mail, la valeur de otp à partir du paramètre de requête doit être transmise au widget en tant qu'option de configuration (ainsi que l'état). Cela garantira que le widget peut charger et reprendre la transaction actuelle.
Par défaut est ['openid', 'email'] . Spécifiez les informations à mettre à disposition dans l' id_token retourné ou access_token . Pour OIDC, vous devez inclure openid comme l'une des lunettes. Pour une liste des étendues disponibles, voir des lunettes et des réclamations.
Afficher l'ordre des fournisseurs d'identité externes par rapport au formulaire de connexion OKTA. Par défaut est SECONDARY .
PRIMARY - Afficher les boutons IDP externes au-dessus du formulaire de connexion OKTASECONDARY - Afficher les boutons IDP externes sous le formulaire de connexion OKTAChemin local ou URL vers une image de logo affichée en haut du widget de connexion
// Hosted on the same origin
logo: '/img/logo.png'
// Can also be a full url
logo: 'https://acme.com/img/logo.png' Texte pour l'attribut alt de l'image du logo, le texte du logo ne s'affiche que lorsque l'image du logo n'est pas disponible
// Text to describe the logo
logoText: 'logo text' La marque ou le nom de l'entreprise affichée dans les messages rendus par le widget de connexion (par exemple, "Réinitialisez votre mot de passe { brandName }"). Si aucun brandName n'est fourni, un message générique est rendu à la place (par exemple, "réinitialiser votre mot de passe"). Vous pouvez personnaliser davantage le texte affiché avec les paramètres de langue et de texte.
brandName: 'Spaghetti Inc.' Ces options vous permettent de personnaliser l'apparence du widget de connexion.
Si vous souhaitez encore plus de personnalisation, vous pouvez modifier les fichiers source SASS et créer le widget.
Définit la couleur de la marque comme couleur d'arrière-plan du bouton CTA primaire. Les couleurs doivent être au format hexadécimal, comme #008000 .
colors: {
brand : '#008000'
}cs - Tchèqueda - danoisde - allemandel - grecen - anglaises - espagnolfi - finnoisfr - françaishu - hongroisid - indonésienit - italienja - Japonaisko - coréenms - Malaisiennb - norvégiennl-NL - néerlandaispl - Polonpt-BR - Portugais (Brésil)ro - roumainru - russesv - suédoisth - thaïtr - turcuk -Uni - Ukrainienzh-CN - Chinois (PRC)zh-TW - Chinois (Taiwan)La prise en charge de langues supplémentaires peut être ajoutée avec l'option Assets.Languages.
Définissez la langue du widget. Si aucune langue n'est spécifiée, le widget choisira une langue basée sur les préférences du navigateur de l'utilisateur si elle est prise en charge, ou par défaut en .
// You can simply pass the languageCode as a string:
language: 'ja'
// Or, if you need to determine it dynamically, you can pass a
// callback function:
language: ( supportedLanguages , userLanguages ) => {
// supportedLanguages is an array of languageCodes, i.e.:
// ['cs', 'da', ...]
//
// userLanguages is an array of languageCodes that come from the user's
// browser preferences
return supportedLanguages [ 0 ] ;
} Définissez le code de country par défaut du widget. Si aucune defaultCountryCode n'est fournie, nous ne US parviens par défaut. Il définit le code d'appel du pays pour le numéro de téléphone en conséquence dans le widget.
Remplacez le texte dans le widget. La liste complète des propriétés se trouve dans les fichiers Login.Properties et Country.Properties.
// The i18n object maps language codes to a hash of property keys ->
// property values.
i18n: {
// Overriding English properties
'en' : {
'primaryauth.title' : 'Sign in to Acme' ,
'primaryauth.username.placeholder' : 'Your Acme Username'
} ,
// Overriding Japanese properties
'ja' : {
'primaryauth.title' : 'ACMEにサインイン' ,
'primaryauth.username.placeholder' : 'ACMEのユーザー名'
}
}
// If you want to override any properties in the country.properties file,
// you will need to prefix the name with "country.":
i18n: {
'en' : {
// login.properties keys do not have a special prefix
'primaryAuth.title' : 'Sign in to Acme' ,
// country.properties keys are prefixed with 'country.'
'country.AF' : 'Afghanistan, edited' ,
'country.AL' : 'Albania, edited'
}
}Remplacez l'URL de base à partir de l'urgence du widget qui tire ses fichiers linguistiques. Le widget n'est emballé qu'avec du texte anglais par défaut et charge d'autres langues à la demande du CDN OKTA. Si vous souhaitez servir les fichiers linguistiques à partir de vos propres serveurs, mettez à jour ce paramètre.
// Loading the assets from a path on the current domain
assets: {
baseUrl : '/path/to/dist'
} ,
// Full urls work as well
assets : {
baseUrl : 'https://acme.com/assets/dist'
}Remarque: Les fichiers JSON sont accessibles à partir du dossier
dist/labels/jsonpublié dans le module NPM.
Spécifiez la liste des langues prises en charge qui sont hébergées et accessibles sous le chemin {assets.baseUrl}/labels/json/ . Cette option remplace la liste par défaut des langues prises en charge. Si une langue non prise en charge est demandée (explicitement à l'aide de l'option de langue ou automatiquement par détection du navigateur), la langue par défaut ( en ) sera utilisée.
Vous pouvez utiliser cette fonction pour réécrire le chemin d'attente et le nom de fichier. Utilisez cette fonction si vous hébergez les fichiers d'actifs sur votre propre hôte et prévoyez de modifier le chemin d'accès ou le nom de fichier des actifs. Ceci est utile, par exemple, si vous souhaitez mettre en cache les fichiers.
assets: {
// Note: baseUrl is still needed to set the base path
baseUrl : '/path/to/dist' ,
rewrite : ( assetPath ) => {
// assetPath is relative to baseUrl
// Example assetPath to load login for 'ja': "/labels/json/login_ja.json"
return someCacheBust ( assetPath ) ;
}
}Définissez l'option de configuration suivante pour remplacer le dos pour connecter l'URL de liaison. S'il n'est pas fourni, le widget accédera à l'authentification principale.
backToSignInLink: 'https://www.backtosignin.com'Remarque: Pour compatibilité avec les versions de widgets précédentes,
signOutLinkest accepté comme un alias pourbackToSignInLink
Vous pouvez ajouter un lien d'enregistrement à la page Auth primaire en définissant les options de configuration suivantes.
Fonction qui s'appelle lorsque le lien d'enregistrement est cliqué.
// An example that adds a registration link underneath the login form on the primary auth page
registration: {
click : ( ) => {
window . location . href = 'https://acme.com/sign-up' ;
}
} Définissez les options de configuration suivantes pour remplacer les URL de liaison d'aide sur la page Auth primaire.
// An example that overrides all help links, and sets two custom links
helpLinks: {
help : 'https://acme.com/help' ,
forgotPassword : 'https://acme.com/forgot-password' ,
unlock : 'https://acme.com/unlock-account' ,
custom : [
{
text : 'What is Okta?' ,
href : 'https://acme.com/what-is-okta'
} ,
{
text : 'Acme Portal' ,
href : 'https://acme.com' ,
target : '_blank'
}
]
} Lien personnalisé HREF pour le lien "Aide"
Lien personnalisé HREF pour le lien "Mot de passe oublié"
Lien personnalisé HREF pour le lien "Déverrouiller le compte". Pour ce lien à afficher, true features.selfServiceUnlock
Tableau d'objets de liaison personnalisé {text, href, target} qui sera ajouté après le lien "Aide". La target du lien est facultative.
Définissez les options de configuration suivantes pour personnaliser le script hCaptcha URI:
// An example that uses cn1 host
hcaptcha : {
scriptSource : 'https://cn1.hcaptcha.com/1/api.js' ,
scriptParams : {
apihost : 'https://cn1.hcaptcha.com' ,
endpoint : 'https://cn1.hcaptcha.com' ,
assethost : 'https://assets-cn1.hcaptcha.com' ,
imghost : 'https://imgs-cn1.hcaptcha.com' ,
reportapi : 'https://reportapi-cn1.hcaptcha.com' ,
}
} , Définissez les options de configuration suivantes pour personnaliser le script reCAPTCHA uri:
// An example that uses recaptcha.net
recaptcha : {
scriptSource : 'https://recaptcha.net/recaptcha/api.js'
} ,Les rappels asynchrones peuvent être invoqués avant ou après une vue spécifique rendue. Les crochets peuvent être utilisés pour ajouter une logique personnalisée telle que l'instrumentation, la journalisation ou une entrée utilisateur supplémentaire. L'exécution normale est bloquée pendant que la fonction de crochet s'exécute et reprendra une fois la promesse renvoyée de la fonction de crochet se résout. Des crochets peuvent être ajoutés via la configuration, comme indiqué ci-dessous, ou au moment de l'exécution à l'aide des méthodes avant ou après. La liste complète des vues peut être trouvée dans RemediationConstants.js.
// Hooks can be set in config
hooks: {
'identify' : {
after : [
async function afterIdentify ( ) {
// custom logic goes here
}
]
} ,
'success-redirect' : {
before : [
async function beforeSuccessRedirect ( ) {
// custom logic goes here
}
]
}
}
// Hooks can also be added at runtime
signIn . before ( 'success-redirect' , async ( ) => {
// custom logic goes here
} ) ;
signIn . after ( 'identify' , async ( ) => {
// custom logic goes here
} ) ;Transforme le nom d'utilisateur avant d'envoyer des demandes avec le nom d'utilisateur à Okta. Ceci est utile lorsque vous avez un mappage interne entre ce que l'utilisateur entre et leur nom d'utilisateur OKTA.
// The callback function is passed two arguments:
// 1) username: The name entered by the user
// 2) operation: The type of operation the user is trying to perform:
// - PRIMARY_AUTH
// - FORGOT_PASSWORD
// - UNLOCK_ACCOUNT
transformUsername: ( username , operation ) => {
// This example will append the '@acme.com' domain if the user has
// not entered it
return username . includes ( '@acme.com' )
? username
: username + '@acme.com' ;
}Des fonctions de rappel peuvent être fournies qui seront appelées à des moments spécifiques du processus d'enregistrement.
registration : {
parseSchema : ( schema , onSuccess , onFailure ) => {
// handle parseSchema callback
onSuccess ( schema ) ;
} ,
preSubmit : ( postData , onSuccess , onFailure ) => {
// handle preSubmit callback
onSuccess ( postData ) ;
} ,
postSubmit : ( response , onSuccess , onFailure ) => {
// handle postsubmit callback
onSuccess ( response ) ;
}
} , Le rappel changeait le schéma JSON qui revient de l'API OKTA.
parseSchema: ( schema , onSuccess ) => {
// This example will add an additional field to the registration form.
schema . push (
{
'name' : 'userProfile.address' ,
'type' : 'text' ,
'placeholder' : 'Enter your street address' ,
'maxLength' : 255 ,
'label-top' : true ,
'label' : 'Street Address' ,
'required' : true ,
}
) ;
onSuccess ( schema ) ;
} Rappel utilisé principalement pour modifier les paramètres de demande envoyés à l'API OKTA.
preSubmit: ( postData , onSuccess ) => {
// This example will append the domain name to the email address if the user forgets to add it during registration.
if ( ! postData . userProfile . email . includes ( '@acme.com' ) ) {
postData . userProfile . email += '@acme.com' ;
}
}
onSuccess ( postData ) ;
} Le rappel utilisé pour obtenir principalement le contrôle et modifier la soumission de post-API à l'enregistrement.
postSubmit: ( response , onSuccess ) => {
// This example will log the API request body to the browser console before completing registration.
console . log ( response ) ;
onSuccess ( response ) ;
} preSubmit: ( postData , onSuccess , onFailure ) => {
// A generic form level error is shown if no error object is provided
onFailure ( ) ;
} preSubmit: ( postData , onSuccess , onFailure ) => {
const error = {
"errorSummary" : "Custom form level error"
} ;
onFailure ( error ) ;
} preSubmit: ( postData , onSuccess , onFailure ) => {
const error = {
"errorSummary" : "API Error" ,
"errorCauses" : [
{
"errorSummary" : "Custom field level error" ,
"property" : "userProfile.email" ,
}
]
} ;
onFailure ( error ) ;
} Vous pouvez ajouter des boutons personnalisés sous le formulaire de connexion sur la page Auth primaire en définissant les options de configuration suivantes. Si vous souhaitez modifier le texte du diviseur, utilisez l'option de configuration i18n .
// An example that adds a custom button below the login form on the Sign in form
customButtons: [ {
title : 'Click Me' ,
className : 'btn-customAuth' ,
click : ( ) => {
// clicking on the button navigates to another page
window . location . href = 'https://www.example.com' ;
}
} ]
// An example that adds a custom button with a localized title below the Sign in form
i18n: {
en : {
'customButton.title' : 'Custom Button Title' ,
} ,
} ,
customButtons : [ {
i18nKey : 'customButton.title' ,
className : 'btn-customAuth' ,
click : ( ) => {
// clicking on the button navigates to another page
window . location . href = 'https://www.example.com' ;
}
} ] Chaîne qui est définie comme le texte du bouton (définissez un seul de title ou i18nKey )
Clé de traduction personnalisée pour le texte du bouton spécifié dans l'option de configuration i18n (définissez un seul de title ou i18nKey )
Classe facultative qui peut être ajoutée au bouton
Fonction qui s'appelle lorsque le bouton est cliqué
Activer ou désactiver les fonctionnalités du widget avec les options suivantes.
features: {
showPasswordToggleOnSignInPage : true ,
hideSignOutLinkInMFA : false ,
rememberMe : true
} Par défaut est true . Affiche l'icône des yeux pour basculer la visibilité du mot de passe entré par l'utilisateur sur la page de connexion OKTA. Le mot de passe est masqué par défaut, même lorsque ce drapeau est activé. Les mots de passe sont visibles pendant 30 secondes, puis cachés automatiquement.
Par défaut est true . Affiche l'identifiant de l'utilisateur sur n'importe quelle vue avec le contexte de l'utilisateur.
Par défaut est false . Cache le lien "Retour pour connecter" pour l'inscription de l'authentificateur et les flux de défi.
Par défaut est true . Pré-remplit le champ Identifiant avec le nom d'utilisateur utilisé précédemment.
Par défaut est true . Focus automatiquement le premier champ de saisie de n'importe quelle forme lorsqu'il est affiché.
Par défaut est false . Définit l'attribut d' off automatique sur les champs d'entrée.
Le widget injecte des blocs de script / style en ligne sécurisé à des fins de conduite à des fins de personnalisation, mais ces blocs peuvent violer les règles CSP qui définissent dans la page Web hébergée.
cspNonce permet de définir la valeur nonce à partir de Content-Security-Policy dans les blocs injectés, de sorte que le script / le style de ces blocs peut toujours être exécutable.
Remarque: La directive NONCE a été ajoutée à CSP Level2, vous pouvez toujours voir les erreurs CSP dans la console de navigateur si elle est utilisée dans les navigateurs non pris en charge.
Événements publiés par le widget. Abonnez-vous à ces événements en utilisant sur.
Déclenché lorsque le widget est prêt à accepter la saisie de l'utilisateur pour la première fois. Renvoie un objet context contenant les propriétés suivantes:
signIn . on ( 'ready' , function ( context ) {
// The Widget is ready for user input
} ) ; Le widget gérera la plupart des types d'erreurs - par exemple, si l'utilisateur entre un mot de passe non valide ou s'il y a des problèmes qui s'authentifient. Pour capturer une erreur de modification de l'état d'authentification une fois qu'elle a été gérée et rendue par le widget, écoutez l'événement afterError . Vous pouvez également capturer des erreurs d'Oauth et d'enregistrement. Pour d'autres types d'erreurs, il est encouragé à les gérer en utilisant le gestionnaire d'erreur renderEl .
Renvoie des objets context et error contenant les propriétés suivantes:
context :error : signIn . on ( 'afterError' , function ( context , error ) {
console . log ( context . controller ) ;
// reset-password
console . log ( error . name ) ;
// AuthApiError
console . log ( error . message ) ;
// The password does not meet the complexity requirements
// of the current password policy.
console . log ( error . statusCode ) ;
// 403
} ) ; Déclenché lorsque le widget passe à une nouvelle page et que les animations ont terminé. Returns a context object containing the following properties:
// Overriding the "Back to sign in" click action on the Forgot Password page
signIn . on ( 'afterRender' , function ( context ) {
if ( context . controller !== 'forgot-password' ) {
return ;
}
var backLink = document . getElementsByClassName ( 'js-back' ) [ 0 ] ;
backLink . addEventListener ( 'click' , function ( e ) {
e . preventDefault ( ) ;
e . stopPropagation ( ) ;
// Custom link behavior
} ) ;
} ) ; We use Yarn as our node package manager. To install Yarn, check out their install documentation.
Clone this repo and navigate to the new okta-signin-widget folder.
git clone https://github.com/okta/okta-signin-widget.git
cd okta-signin-widgetInstall our Node dependencies.
yarn install Create a .widgetrc.js file in the okta-signin-widget directory with your desired configuration:
module . exports = {
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : '{{clientId of your OIDC app}}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
logoText : 'Windico' ,
features : {
rememberMe : true ,
} ,
}Build the widget, start a local connect server that hosts it, and launch a browser window with the widget running.
yarn start or start local connect server in watch mode, changes in src/ and assets/sass/ folders will trigger browser auto reload.
yarn start --watchFinally, enable CORS support for our new server by following these instructions. You can now authenticate to Okta using your very own, customizable widget!
| Commande | Description |
|---|---|
yarn start | Build the widget, start the server, and open a browser window with the widget loaded |
yarn start --watch | Build the widget, start the server, and open a browser window with the widget loaded and watch on widget js and sass changes |
yarn build:dev | Build an unminified version of the widget |
yarn build:release | Build a minified, uglified version of the widget ( okta-sign-in.min.js ) and a non-minified development version of the widget ( okta-sign-in.js ). |
yarn test -t jest | Run unit tests using Jest |
yarn test -t jest --suiteHelp | Display optional test suite options |
yarn test -t testcafe <browser> | Run testcafe tests on selected browser (example: yarn test -t testcafe chrome ) |
yarn lint | Run eslint and scss linting tests |
yarn link When developing locally, you may want to test local changes to the widget in another project, which is also local. To use yarn link locally, follow these steps:
In okta-signin-widget directory:
yarn build:release
cd dist
yarn link
yarn build:webpack-dev --output-path ./dist/js --output-filename okta-sign-in.entry.js --watchThis will watch for changes in signin widget source code and automatically rebuild to the dist directory.
In your other local project directory:
yarn link @okta/okta-signin-widget
️ This tool requires access to Okta's internal registry via the VPN.
A pseudo-localized language is a test language created to identify issues with the internationalization process. Generated from login.properties English resources, the pseudo-loc properties file can be used to test UI's for English leaks and CSS layout issues caused due to localization.
To generate pseudo-loc, run the following command:
# Navigate into the pseudo-loc package
[okta-signin-widget]$ cd packages/@okta/pseudo-loc/
# Install all required dependencies and generate login_ok_PL.properties
# NOTE: This requires VPN access
[pseudo-loc]$ yarn install
[pseudo-loc]$ yarn pseudo-loc Finally, update the .widgetrc.js file to use the ok_PL language, and start the widget playground.
module . exports = {
// ...other widget config
// ...
language : 'ok-PL' ,
...
} Need to know if the Sign-In Widget supports your browser requirements? Please see Platforms, Browser, and OS Support.
We're happy to accept contributions and PRs! Please see the contribution guide to understand how to structure a contribution.
