okta auth js
7.8.1
Okta Auth JavaScript SDK는 인증 API와 OpenID Connect 및 OAuth 2.0 API를 기반으로 구축되어 JavaScript를 사용하여 완전한 브랜드 로그인 환경을 만들 수 있도록 해줍니다.
자세한 내용은 설명서의 Okta + JavaScript 페이지에서 알아볼 수 있습니다.
이 라이브러리는 의미 체계 버전 관리를 사용하고 Okta의 라이브러리 버전 정책을 따릅니다.
️ ️ ️ ️ ️ ️ ️ ️ ️
️ ️ ️ ️ ️ ️ ️ ️ ️
✔️ 현재 안정적인 주요 버전 시리즈는 7.x 입니다.
| 버전 | 상태 |
|---|---|
7.x | ✔️ 안정적 |
6.x | 은퇴 |
5.x | 은퇴 |
4.x | 은퇴 |
3.x | 은퇴 |
2.x | 은퇴 |
1.x | 은퇴 |
0.x | 은퇴 |
최신 릴리스는 항상 릴리스 페이지에서 찾을 수 있습니다.
SDK 사용에 문제가 발생하면 다음을 수행할 수 있습니다.
이 SDK의 이전 버전에서 마이그레이션하는 사용자는 마이그레이션 가이드를 참조하여 어떤 변경이 필요한지 알아보세요.
이 SDK는 데스크톱 및 모바일의 최신 버전의 Chrome, Firefox 및 Safari에서 작동하는 것으로 알려져 있습니다.
IE 11/Edge와의 호환성은 다음 개체에 대해 폴리필/심을 추가하여 달성할 수 있습니다.
️ 암호화 폴리필은 좋은 암호화의 핵심인 의사 난수를 생성하는 데 사용되는 고품질 엔트로피의 소스로 운영 체제를 사용할 수 없습니다. 따라서 우리는 암호화 폴리필이 덜 안전하다는 입장을 취하고 있으며 이를 사용하지 않는 것이 좋습니다.
이 모듈은 필요한 모든 폴리필을 구현하는 진입점을 제공합니다.
브라우저의 웹 페이지에서 JS를 사용하는 경우 node_modules/@okta/okta-auth-js/dist 콘텐츠를 공개 호스팅 디렉터리에 복사하고 okta-auth-js.polyfill.js <script> 태그에 okta-auth-js.polyfill.js 파일을 추가하세요. 이는 폴리필에 의존하는 다른 스크립트보다 먼저 로드되어야 합니다.
Webpack 또는 Browserify와 같은 번들러를 사용하는 경우 간단히 import import 또는 require @okta/okta-auth-js/polyfill 애플리케이션 코드 시작 부분이나 그 근처에서 사용할 수 있습니다.
import '@okta/okta-auth-js/polyfill' ;또는
require ( '@okta/okta-auth-js/polyfill' ) ;빌드된 폴리필 번들은 글로벌 CDN에서도 사용할 수 있습니다. 다른 스크립트보다 먼저 로드하려면 HTML 파일에 다음 스크립트를 포함하세요.
< script src =" https://global.oktacdn.com/okta-auth-js/7.5.1/okta-auth-js.polyfill.js " type =" text/javascript " integrity =" sha384-EBFsuVdi4TGp/DwS7b+t+wA8zmWK10omkX05ZjJWQhzWuW31t7FWEGOnHQeIr8+L " crossorigin =" anonymous " > </ script >
️ 이 샘플에 표시된 버전은 현재 버전보다 이전 버전일 수 있습니다. 사용 가능한 가장 높은 버전을 사용하는 것이 좋습니다.
많은 브라우저는 기본적으로 교차 출처 또는 "제3자" 쿠키를 차단하기 시작했습니다. 이 SDK에서 지원하는 대부분의 Okta API는 쿠키에 의존하지 않지만 쿠키에 의존하는 몇 가지 방법이 있습니다. 타사 쿠키가 차단되면 다음 방법이 중단됩니다.
애플리케이션이 이러한 방법 중 하나에 의존하는 경우 이러한 방법을 사용하지 않도록 애플리케이션을 다시 작성하거나 사용자에게 타사 쿠키를 활성화해야 한다는 점을 알려야 합니다. Okta 엔지니어들은 현재 이 문제에 대한 더 나은 장기적인 솔루션을 연구하고 있습니다.
인증 SDK 설치는 간단합니다. npm 패키지 @okta/okta-auth-js를 통해 프로젝트에 이를 포함할 수 있습니다.
또한 다음이 필요합니다.
새로운 Okta 애플리케이션을 생성할 때 애플리케이션 유형을 지정할 수 있습니다. 이 SDK는 SPA (단일 페이지 애플리케이션) 또는 Web 애플리케이션과 함께 작동하도록 설계되었습니다. SPA 애플리케이션은 클라이언트 측에서 모든 논리 및 권한 부여 흐름을 수행합니다. Web 애플리케이션은 서버에서 인증 흐름을 수행합니다.
Okta 관리 UI에서 Applications 클릭한 다음 애플리케이션을 선택합니다. 애플리케이션의 General 탭에서 Okta 애플리케이션의 구성을 보고 편집할 수 있습니다.
Okta 애플리케이션을 고유하게 식별하는 문자열입니다.
사용자를 로그인하기 위해 애플리케이션은 브라우저를 Okta에서 호스팅하는 로그인 페이지로 리디렉션합니다. 그런 다음 Okta는 사용자에 대한 정보를 사용하여 애플리케이션으로 다시 리디렉션합니다. Okta 호스팅 흐름에서 이것이 어떻게 작동하는지 자세히 알아볼 수 있습니다.
Okta 애플리케이션 설정에서 로그인 리디렉션 URL을 허용 목록에 추가해야 합니다.
앱과 Okta에서 사용자를 로그아웃시킨 후 사용자를 애플리케이션의 특정 위치로 리디렉션해야 합니다. Okta 애플리케이션 설정에서 로그아웃 후 URL을 허용 목록에 추가해야 합니다.
다음과 같은 경우 npm 모듈을 사용하는 것이 좋습니다.
@okta/okta-auth-js를 설치하려면:
# Run this command in your project root folder.
# yarn
yarn add @okta/okta-auth-js
# npm
npm install --save @okta/okta-auth-js 브라우저의 웹 페이지에서 JS를 사용하는 경우 node_modules/@okta/okta-auth-js/dist 콘텐츠를 공개 호스팅 디렉터리에 복사하고 okta-auth-js.min.js <script> 태그에 okta-auth-js.min.js 파일을 추가하세요.
빌드된 라이브러리 번들은 글로벌 CDN에서도 사용할 수 있습니다. 애플리케이션 스크립트 전에 로드할 HTML 파일에 다음 스크립트를 포함합니다.
< script src =" https://global.oktacdn.com/okta-auth-js/7.5.1/okta-auth-js.min.js " type =" text/javascript " integrity =" sha384-6epSwnIDkI5zFNEVNjEYy3A7aSZ+C7ehmEyG8zDJZfP9Bmnxc51TK8du+2me4pjb " crossorigin =" anonymous " > </ script >
️ 이 샘플에 표시된 버전은 현재 버전보다 이전 버전일 수 있습니다. 사용 가능한 가장 높은 버전을 사용하는 것이 좋습니다.
그런 다음 전역적으로 사용 가능한 OktaAuth 객체의 인스턴스를 생성할 수 있습니다.
const oktaAuth = new OktaAuth ( {
// config
} )그러나 Webpack 또는 Rollup과 같은 번들러를 사용하는 경우 간단히 모듈을 가져오거나 요구할 수 있습니다.
// ES module
import { OktaAuth } from '@okta/okta-auth-js'
const authClient = new OktaAuth ( /* configOptions */ ) // CommonJS
var OktaAuth = require ( '@okta/okta-auth-js' ) . OktaAuth ;
var authClient = new OktaAuth ( /* configOptions */ ) ; 클라이언트 기능 및 인증 흐름에 대한 개요를 보려면 개발자 문서를 확인하세요. 여기서는 간단한 정적 페이지에서 Auth SDK를 사용하여 다음을 수행하는 방법을 배웁니다.
️ 개발자 문서는 이 라이브러리의 이전 버전에 대해 작성되었을 수 있습니다. 이전 버전에서 마이그레이션을 참조하세요.
전체 API 참조 문서를 찾아볼 수도 있습니다.
⌛ 비동기 메소드는 성공 시 해결될 약속을 반환합니다. 오류가 발생하면 약속이 거부될 수 있습니다.
var config = {
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : 'GHtf9iJdr60A9IYrR0jw' ,
redirectUri : 'https://acme.com/oauth2/callback/home' ,
} ;
var authClient = new OktaAuth ( config ) ; 기본적으로 OktaAuth 의 새 인스턴스를 생성해도 비동기 부작용이 발생하지 않습니다. 그러나 토큰 자동 갱신, 토큰 자동 제거 및 탭 간 동기화와 같은 특정 기능을 사용하려면 OktaAuth 서비스로 실행되어야 합니다. 이는 서비스가 중지될 때까지 계속 작동하는 시간 초과가 백그라운드에서 설정됨을 의미합니다. OktaAuth 서비스를 시작하려면 생성 직후, handlerRedirect와 같은 다른 메소드를 호출하기 전에 start 메소드를 호출하면 됩니다. 모든 백그라운드 프로세스를 종료하려면 stop 호출하세요. 자세한 내용은 서비스 구성을 참조하세요.
var authClient = new OktaAuth ( config ) ;
await authClient . start ( ) ; // start the service
await authClient . stop ( ) ; // stop the service참고: 서비스를 시작하면 authStateManager.updateAuthState도 호출됩니다.
유형 정의는 package.json 의 types 항목을 통해 암시적으로 제공됩니다. 유형을 가져와서 명시적으로 참조할 수도 있습니다.
import {
OktaAuth ,
OktaAuthOptions ,
TokenManagerInterface ,
AccessToken ,
IDToken ,
UserClaims ,
TokenParams
} from '@okta/okta-auth-js' ;
const config : OktaAuthOptions = {
issuer : 'https://{yourOktaDomain}'
} ;
const authClient : OktaAuth = new OktaAuth ( config ) ;
const tokenManager : TokenManagerInterface = authClient . tokenManager ;
const accessToken : AccessToken = await tokenManager . get ( 'accessToken' ) as AccessToken ;
const idToken : IDToken = await tokenManager . get ( 'idToken' ) as IDToken ;
const userInfo : UserClaims = await authClient . token . getUserInfo ( accessToken , idToken ) ;
if ( ! userInfo ) {
const tokenParams : TokenParams = {
scopes : [ 'openid' , 'email' , 'custom_scope' ] ,
} ;
authClient . token . getWithRedirect ( tokenParams ) ;
} 3.6 이전의 Typescript 버전에는 WebAuthn에 대한 유형 정의가 없습니다. IDX API의 WebAuthn 지원은 @okta/[email protected] 에 도입되었습니다. 이 문제를 해결하려면 @types/webappsec-credential-management 버전 ^0.5.1 패키지를 설치하십시오.
웹 및 기본 클라이언트는 보안 위치에 저장된 클라이언트 암호를 사용하는 authorization_code 흐름을 사용하여 토큰을 얻을 수 있습니다. (SPA 애플리케이션은 클라이언트 비밀을 사용하지 않는 PKCE 흐름을 사용해야 합니다.) authorization_code 흐름을 사용하려면 responseType "code" 로 설정하고 pkce false 로 설정합니다.
var config = {
// Required config
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : 'GHtf9iJdr60A9IYrR0jw' ,
redirectUri : 'https://acme.com/oauth2/callback/home' ,
// Use authorization_code flow
responseType : 'code' ,
pkce : false
} ;
var authClient = new OktaAuth ( config ) ; PKCE OAuth 흐름이 기본적으로 사용됩니다. 이 라이브러리는 브라우저와 NodeJS 애플리케이션 모두에 대해 PKCE를 지원합니다. PKCE는 HTTPS 연결에서 실행될 때 대부분의 최신 브라우저에서 널리 지원됩니다. PKCE를 사용하려면 브라우저가 crypto.subtle ( webcrypto 라고도 함)을 구현해야 합니다. 대부분의 최신 브라우저는 보안 컨텍스트(HTTPS 연결)에서 실행될 때 이를 제공합니다. PKCE에는 TextEncoder 개체도 필요합니다. 이는 IE 11 및 Edge <v79를 제외한 모든 주요 브라우저에서 사용할 수 있습니다. 지원을 추가하려면 텍스트 인코딩과 같은 폴리필/심을 사용하는 것이 좋습니다.
사용자의 브라우저가 PKCE를 지원하지 않으면 예외가 발생합니다. 이 정적 메서드를 사용하면 구성 전에 브라우저가 PKCE를 지원하는지 테스트할 수 있습니다.
OktaAuth.features.isPKCESupported()
️ 암시적 흐름을 사용하는 것은 강력히 권장하지 않습니다. 가능하면 PKCE 및/또는 클라이언트 자격 증명을 사용하십시오.
배포에서 PKCE 흐름을 지원할 수 없는 경우 암시적 OAuth 흐름을 옵션으로 사용할 수 있습니다. 대부분의 브라우저에서 널리 지원되며 안전하지 않은 HTTP 연결을 통해 작동할 수 있습니다. 원시 토큰이 브라우저 기록에 노출되므로 암시적 흐름은 HTTPS를 통해서도 PKCE 흐름보다 덜 안전합니다. 이러한 이유로 가능하면 PKCE 흐름을 사용하는 것이 좋습니다.
pkce 옵션을 false 로 설정하면 암시적 흐름을 활성화할 수 있습니다.
var config = {
pkce : false ,
// other config
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
} ;
var authClient = new OktaAuth ( config ) ;사용자를 로그인하려면 애플리케이션이 브라우저를 Okta 호스팅 로그인 페이지로 리디렉션해야 합니다.
참고: Okta 호스팅 로그인 페이지로의 초기 리디렉션은 stateToken 수명이 1시간으로 설정된 트랜잭션을 시작합니다.
인증이 성공적으로 완료되면 브라우저는 사용자에 대한 정보와 함께 애플리케이션으로 다시 리디렉션됩니다. 기본 설정에 따라 다음 콜백 전략을 사용할 수 있습니다.
대부분의 애플리케이션은 로그인 페이지와 별도로 특수 경로/페이지를 사용하여 OAuth 콜백을 처리합니다. 그러나 일부 SPA 애플리케이션에는 라우팅 논리가 없으며 단일 페이지에서 모든 것을 처리하려고 합니다.
async function main ( ) {
// create OktaAuth instance
var config = {
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : 'GHtf9iJdr60A9IYrR0jw' ,
redirectUri : 'https://acme.com/oauth2/callback/home' ,
} ;
authClient = new OktaAuth ( config ) ;
// Subscribe to authState change event.
authClient . authStateManager . subscribe ( function ( authState ) {
// Logic based on authState is done here.
if ( ! authState . isAuthenticated ) {
// render unathenticated view
return ;
}
// Render authenticated view
} ) ;
// Handle callback
if ( authClient . token . isLoginRedirect ( ) ) {
const { tokens } = await authClient . token . parseFromUrl ( ) ; // remember to "await" this async call
authClient . tokenManager . setTokens ( tokens ) ;
}
// normal app startup
authClient . start ( ) ; // will update auth state and call event listeners
} OAuth 2.0 사양에 따르면 리디렉션 URI는 "조각 구성 요소를 포함해서는 안 됩니다": https://tools.ietf.org/html/rfc6749#section-3.1.2 해시/조각 라우팅 전략과 OAuth 2.0을 사용하는 경우 리디렉션 콜백이 기본/기본 경로가 됩니다. 리디렉션 콜백 흐름은 라우팅 없이 콜백을 처리하는 것과 매우 유사합니다. 다른 인증 확인 전에 앱 시작 부분에서 리디렉션 URL을 구문 분석하는 논리를 정의하는 것이 좋습니다.
또한 해시 라우팅을 사용하는 경우 PKCE 및 responseMode "query"(PKCE의 기본값)를 사용하는 것이 좋습니다. 암시적 흐름을 사용하면 해시 라우터가 조각을 다시 쓸 수 있으므로 해시의 토큰으로 인해 예측할 수 없는 결과가 발생할 수 있습니다.
TokenManager 에 토큰 추가: tokenManager.setTokens참고: DPoP(소유 증명 증명) - RFC9449
DPoP 활성화해야 합니다(가이드: DPoP 구성).https 필요합니다. WebCrypto.subtle 에는 보안 컨텍스트가 필요합니다.IndexedDB (MDN, caniuse)를 지원해야 합니다. const config = {
// other configurations
pkce : true , // required
dpop : true ,
} ;
const authClient = new OktaAuth ( config ) ; 참조: DPoP 인증 체계 (RFC9449)
GET /protectedresource HTTP/1.1
Host: resource.example.org
Authorization: DPoP Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsIm...
async function dpopAuthenticatedFetch ( url , options ) {
const { method } = options ;
const dpop = await authClient . getDPoPAuthorizationHeaders ( { url , method } ) ;
// dpop = { Authorization: "DPoP token****", Dpop: "proof****" }
const headers = new Headers ( { ... options . headers , ... dpop } ) ;
return fetch ( url , { ... options , headers } ) ;
} use_dpop_nonce 처리참조: 리소스 서버 제공 Nonce (RFC9449)
리소스 서버는 전송되는 DPoP 증명에 포함될 nonce 값을 제공하도록 선택할 수도 있습니다. 인증 서버와 동일한 방식으로 DPoP-Nonce 헤더를 사용하여 nonce를 제공합니다.
HTTP/1.1 401 Unauthorized
WWW-Authenticate: DPoP error="use_dpop_nonce",
error_description="Resource server requires nonce in DPoP proof"
DPoP-Nonce: eyJ7S_zG.eyJH0-Z.HX4w-7v
async function dpopAuthenticatedFetch ( url , options ) {
// ...previous example...
const resp = await fetch ( url , { ... options , headers } ) ;
// resp = HTTP/1.1 401 Unauthorized...
if ( ! resp . ok ) {
const nonce = authClient . parseUseDPoPNonceError ( resp . headers ) ;
if ( nonce ) {
const retryDpop = await authClient . getDPoPAuthorizationHeaders ( { url , method , nonce } ) ;
const retryHeaders = new Headers ( { ... options . headers , ... retryDpop } ) ;
return fetch ( url , { ... options , headers : retryHeaders } ) ;
}
}
return resp ;
} DPoP에는 특정 브라우저 기능이 필요합니다. 필수 기능 없이 브라우저를 사용하는 사용자는 토큰 요청을 완료할 수 없습니다. 애플리케이션 부트스트래핑 중에 브라우저 지원을 확인하는 것이 좋습니다.
// App.tsx
useEffect ( ( ) => {
if ( ! authClient . features . isDPoPSupported ( ) ) {
// user will be unable to request tokens
navigate ( '/unsupported-error-page' ) ;
}
} , [ ] ) ; DPoP를 사용하려면 스토리지에 유지되어야 하는 CryptoKeyPair 생성이 필요합니다. signOut() 또는 revokeAccessToken() 과 같은 메서드는 키 쌍을 삭제하지만 사용자가 항상 명시적으로 로그아웃하는 것은 아닙니다. 따라서 이전에 요청한 토큰에서 생성된 분리된 키 쌍을 플러시하기 위해 로그인하기 전에 저장소를 지우는 것이 좋습니다.
async function login ( options ) {
await authClient . clearDPoPStorage ( ) ; // clear possibly orphaned key pairs
return authClient . signInWithRedirect ( options ) ;
} 이 SDK를 사용하여 OIDC 흐름을 구현하거나 인증 API와 통신하는 경우 유일하게 필요한 구성 옵션은 Okta 인증 서버의 URL인 issuer 입니다.
Okta 조직의 URL을 발급자로 사용할 수 있습니다. 그러면 기본 권한 부여 정책이 적용되고 조직 수준에서 범위가 지정된 토큰이 발행됩니다.
var config = {
issuer : 'https://{yourOktaDomain}'
} ;
var authClient = new OktaAuth ( config ) ;Okta를 사용하면 자체 리소스 서버를 보호하는 데 사용할 수 있는 여러 사용자 정의 OAuth 2.0 인증 서버를 생성할 수 있습니다. 각 인증 서버 내에서 자체 OAuth 2.0 범위, 클레임 및 액세스 정책을 정의할 수 있습니다. 많은 조직에는 "기본" 인증 서버가 있습니다.
var config = {
issuer : 'https://{yourOktaDomain}/oauth2/default'
} ;
var authClient = new OktaAuth ( config ) ;추가 인증 서버를 생성하고 사용자 정의할 수도 있습니다.
var config = {
issuer : 'https://{yourOktaDomain}/oauth2/custom-auth-server-id'
} ;
var authClient = new OktaAuth ( config ) ; 이러한 옵션은 Okta Auth JS( new OktaAuth(config) )를 인스턴스화할 때 포함될 수 있습니다.
issuer
️ 이 옵션은 필수입니다
Okta 조직 또는 Okta 인증 서버의 URL입니다. 발행자 정보
clientIdOIDC 인증 흐름을 위해 Okta에 사전 등록된 클라이언트 ID입니다. Okta 애플리케이션 만들기
redirectUri token.getWithRedirect 사용 시 리디렉션되는 URL입니다. 이는 Okta 애플리케이션의 로그인 리디렉션 URI에 나열되어야 합니다. redirectUri 제공되지 않으면 기본값은 현재 원본( window.location.origin )입니다. Okta 애플리케이션 구성
postLogoutRedirectUri 로그아웃 후 브라우저가 리디렉션되어야 하는 URL을 지정합니다. 이 URL은 Okta 애플리케이션의 로그아웃 리디렉션 URI에 나열되어야 합니다. 지정하지 않으면 애플리케이션의 원본( window.location.origin )이 사용됩니다. Okta 애플리케이션 구성 |
scopes 반환된 id_token 또는 access_token 에서 사용할 수 있는 정보를 지정합니다. OIDC의 경우 openid 범위 중 하나로 포함해야 합니다. 기본값은 ['openid', 'email'] 입니다. 사용 가능한 범위 목록은 범위 및 클레임을 참조하세요.
state서버 엔드포인트에 전달되고 OAuth 응답으로 반환되는 클라이언트 제공 문자열입니다. 이 값은 OAuth 응답의 유효성을 검사하고 CSRF(교차 사이트 요청 위조)를 방지하는 데 사용될 수 있습니다. 기본값은 임의의 문자열입니다.
pkce PKCE OAuth 흐름을 활성화하는 기본값은 true 입니다. 암시적 흐름 또는 인증 코드 흐름을 사용하려면 pkce false 로 설정하세요.
dpop 기본값은 false 입니다. DPoP (소유 증명 증명(RFC9449))을 활성화하려면 true 로 설정합니다.
가이드 보기: DPoP 활성화
token.getWithRedirect 값을 사용하여 토큰을 요청하면 리디렉션Uri에 추가된 매개변수로 반환됩니다.
대부분의 경우 responseMode 값을 설정할 필요가 없습니다. 기본값은 OpenID Connect 1.0 사양에 따라 설정됩니다.
PKCE OAuth 흐름)의 경우 인증 코드는 URL의 검색어에 포함됩니다. PKCE 흐름을 사용하는 클라이언트는 responseMode 옵션을 "fragment"로 설정하여 대신 해시 조각으로 인증 코드를 받도록 선택할 수 있습니다.
암시적 OAuth 흐름의 경우 토큰은 URL의 해시 조각에 있습니다. 이는 변경할 수 없습니다.
responseType 암시적 OAuth 흐름을 사용할 때 OIDC 인증에 대한 응답 유형을 지정합니다. 기본값은 액세스 토큰과 ID 토큰을 모두 요청하는 ['token', 'id_token'] 입니다. pkce 가 true 이면 액세스 및 ID 토큰이 모두 요청되며 이 옵션은 무시됩니다. authorization_code 흐름을 사용하는 웹/네이티브 애플리케이션의 경우 이 값은 "code" 로 설정되어야 하고 pkce false 로 설정되어야 합니다.
authorizeUrlOIDC 흐름을 수행하려면 사용자 정의 AuthorizeUrl을 지정하세요. 기본값은 발급자와 "/v1/authorize"입니다.
userinfoUrl사용자 정의 userinfoUrl을 지정합니다. 기본값은 발급자와 "/v1/userinfo"입니다.
tokenUrl사용자 정의 tokenUrl을 지정합니다. 기본값은 발급자와 "/v1/token"입니다.
ignoreSignature
️ 이 옵션은 브라우저 지원 및 테스트 목적으로만 사용해야 합니다.
ID 토큰 서명은 token.getWithoutPrompt , token.getWithPopup , token.getWithRedirect 및 token.verify 가 호출될 때 기본적으로 유효성이 검사됩니다. 이러한 메소드에 대한 ID 토큰 서명 유효성 검증을 비활성화하려면 이 값을 true 로 설정하십시오.
maxClockSkew기본값은 300(5분)입니다. 이는 토큰을 검증할 때 클라이언트 시계와 Okta 시계 간에 허용되는 최대 차이(초)입니다. 이 값을 0으로 설정하면 유효한 토큰이 유효성 검사에 실패할 가능성이 높아지므로 권장되지 않습니다.
ignoreLifetime
️ 이 옵션은 보안 취약성 문제를 일으킬 수 있는 토큰 수명 유효성 검사를 비활성화합니다. 이 옵션은 테스트 목적으로 사용해야 합니다. 프로덕션 환경에서는 자체 앱에서 오류를 처리하시기 바랍니다.
토큰 수명은 maxClockSkew를 사용하여 검증됩니다. 이를 재정의하고 토큰 수명 유효성 검사를 비활성화하려면 이 값을 true 로 설정하세요.
transformAuthState 콜백 함수. updateAuthState가 호출되면 새로운 authState 객체가 생성됩니다. transformAuthState 함수를 제공하면 이 객체를 저장하고 내보내기 전에 수정하거나 교체할 수 있습니다. 일반적인 사용 사례는 isAuthenticated의 의미를 변경하는 것입니다. 기본적으로 updateAuthState 만료되지 않은 토큰을 tokenManager에서 사용할 수 있는 경우 authState.isAuthenticated true로 설정합니다. 유효한 Okta SSO 세션도 요구하도록 이 논리를 사용자 정의할 수 있습니다.
const config = {
// other config
transformAuthState : async ( oktaAuth , authState ) => {
if ( ! authState . isAuthenticated ) {
return authState ;
}
// extra requirement: user must have valid Okta SSO session
const 
