## Introductie [Logto](https://logto.io/) biedt onze ontwikkelaars en zakelijke groepen een uitgebreide Customer Identity and Access Management (CIAM) oplossing. We bieden een breed scala aan kant-en-klare SDK's voor verschillende platforms en applicatiekaders. Gecombineerd met onze Logto cloudservice, kun je moeiteloos een zeer veilige gebruikersautorisatiestroom voor je applicatie in slechts enkele minuten opzetten. Als een bedrijf dat is ontstaan uit de ontwikkelaarsgemeenschap, omarmt en waardeert Logto onze betrokkenheid bij de gemeenschap. Naast de officieel ontwikkelde Logto SDK's, moedigen we ontwikkelaars uit de gemeenschap continu aan en verwelkomen we ze om hun expertise bij te dragen door meer diverse en gebruiksvriendelijke SDK's te creëren, waarmee aan de unieke behoeften van verschillende platforms en kaders wordt voldaan. In dit artikel zullen we kort demonstreren hoe je stapsgewijs een OIDC-standaard authenticatie SDK implementeert. Maak je applicatie aan in Logto ## Context De OpenID Connect (OIDC) flow is een authenticatieprotocol dat voortbouwt op het OAuth 2.0-kader om identiteitsverificatie en single sign-onmogelijkheden te bieden. Het stelt gebruikers in staat zichzelf bij een applicatie te authenticeren en verder veilig toegang te krijgen tot privébronnen. Raadpleeg de OIDC-specificaties voor meer details. ### Werkstroom Een standaard autorisatiecode-flow omvat de volgende stappen: ```mermaid sequenceDiagram actor user as Eindgebruiker participant app as Client-app participant server as Autorisatieserver participant resource as Privébronnen user ->> app: anonieme bezoeker aanmelding app ->> server: stuur authenticatieverzoek server -->> user: omleiden naar de aanmeldingspagina van de gebruiker user ->> server: aanmelden met inloggegevens server -->> app: omleiden terug naar de client-app met authorization_code app ->> server: aanvraag tokenuitwisseling met de authorization_code server ->> app: verleen id_token, access_token en refresh_token app -->> user: geauthenticeerd app ->> resource: prive API-verzoek met access_token resource --> server: synchroniseer ondertekeningssleutel resource -->> resource: tokenvalidatie resource ->> app: 200 OK ``` #### Authenticatiestroom 1. **Gebruiker initieert het aanmeldverzoek:** Een anonieme gebruiker komt via een openbare ingang bij je applicatie. Proberen zich te authenticeren en misschien verder vragen om toegang tot een beschermd middel op een applicatie of dienst van een derde partij. 2. **Gebruikersauthenticatie:** De client-app genereert een authenticatie-URI en stuurt een verzoek naar de autorisatieserver, die de gebruiker omleidt naar zijn aanmeldingspagina. De gebruiker interacteert met de aanmeldingspagina met behulp van een breed scala aan aanmeldmethoden en wordt geauthenticeerd door de autorisatieserver. 3. **Afhandelen van aanmeldingscallback**: Na succesvolle authenticatie wordt de gebruiker teruggeleid naar jouw applicatie met een verleende `authorization_code`. Deze `authorization_code` bevat alle relevante machtigingen die zijn gekoppeld aan de authenticatiestatus en gevraagde autorisatiegegevens. 4. **Tokenuitwisseling**: Doe een verzoek om tokenuitwisseling met de `authorization_code` die is opgehaald uit het bovenstaande redirectadres. In ruil daarvoor: - `id_token`: Een digitaal ondertekende JWT die identiteitsinformatie bevat over de geauthenticeerde gebruiker. - `access_token`: Een ondoorzichtige `access_token` die kan worden gebruikt om toegang te krijgen tot het gebruikersinfo-eindpunt. - `refresh_token`: Het token waarmee de gebruiker een continue uitwisseling voor een `access_token` kan behouden. #### Autorisatiestroom 1. **Toegang tot gebruikersinformatie**: Om meer gebruikersinformatie te benaderen, kan de applicatie aanvullende verzoeken doen aan het UserInfo-eindpunt, gebruikmakend van de ondoorzichtige `access_token` verkregen uit de initiële tokenuitwisselingsflow. Dit maakt een retrieval mogelijk van aanvullende gegevens over de gebruiker, zoals hun e-mailadres of profielfoto. 2. **Toegang verlenen tot het beschermde middel**: Indien nodig kan de applicatie aanvullende verzoeken doen aan het tokenuitwisselingsendpunt, gebruikmakend van de `refresh_token` gecombineerd met `resource` en `scope` parameters, om een speciale `access_token` voor de gebruiker te verkrijgen om toegang te krijgen tot het doelmiddel. Dit proces resulteert in de uitgifte van een JWT-geformateerde `access_token` die alle benodigde autorisatie-informatie bevat om toegang te krijgen tot het beschermde middel. ## Implementatie We zullen enkele ontwerpstrategieën volgen binnen onze @logto/client JavaScript SDK om het proces van het implementeren van een eenvoudige SDK voor je eigen client applicatie te demonstreren. Houd er rekening mee dat de gedetailleerde code structuur kan verschillen, afhankelijk van het client framework waarmee je werkt. Voel je vrij om een van de officiële Logto SDK's als voorbeeld voor je eigen SDK project te kiezen. ### Voorbeeld ```ts class LogtoClient { protected readonly logtoConfig: LogtoConfig; protected readonly storage: Storage; protected oidcConfig: OidcConfig; protected accessTokenMap: Map constructor(logtoConfig: LogtoConfig) {} get async idToken(){} private async getOidcConfig(){} private async getJwksFunction() {} private async verifyIdToken() {} private async saveTokens() {} private async setSignInSession() {} private async getSignInSession() {} private async getAccessTokenByRefreshToken() {} async signIn(redirectUri: string) {} async handlerSignInCallback (callbackUri: string) {} async getUserInfo() {} async getAccessToken(resource?: string, scopes?: string[]) {} } ``` ### Constructor De constructor moet een [logtoConfig](#logto-config) als invoer nemen. Dit biedt alle nodige configuraties die je nodig hebt om een authenticatieverbinding tot stand te brengen via deze SDK. Afhankelijk van het platform of kader dat je gebruikt voor de SDK, kun je een instance van een persistente lokale opslag aan de constructor doorgeven. Deze opslaginstance wordt gebruikt om alle autorisatie-gerelateerde tokens en geheimen op te slaan. ```ts class LogtoClient { constructor(logtoConfig: LogtoConfig, storage: Storage) {} } ``` ### Initiëer gebruikersauthenticatie Voordat je een authenticatieverzoek-URL kunt genereren, is het essentieel om verschillende voorbereidende stappen te voltooien om een veilig proces te waarborgen. #### Verkrijg OIDC-configuraties van de autorisatieserver Definieer een privé methode `getOidcConfigs` om OIDC-configuraties op te halen van het ontdekkingsendpunt van de autorisatieserver. De OIDC-configuraties reactie bevat alle metadata informatie die de client kan gebruiken om te communiceren met de autorisatieserver, inclusief zijn eindpuntlocaties en de mogelijkheden van de server. (Raadpleeg [OAuth OAuth Authorization Server Metadata Specs](https://datatracker.ietf.org/doc/html/rfc8414) voor meer details.) ```ts const discoveryPath = "/oidc/.well-known/openid-configuration"; private async getOidcConfigs() { if (this.oidcConfig) { return this.oidcConfig; } const response = await fetch(`${this.logtoConfig.endpoint}${discoveryPath}`) this.oidcConfig = await response.json(); return this.oidcConfig; } ``` #### PKCE Generator Een [PKCE(Proof Key for Code Exchange)](https://datatracker.ietf.org/doc/html/rfc7636) validatiestroom is essentieel voor alle openbare client autorisatiecode uitwisselingsflows. Het vermindert het risico van onderschepping van authorization_code aanvallen. Dus een `code_challenge` en `code_verifier` is vereist voor alle openbare client applicaties (bijv. native app en SPA) autorisatieverzoeken. De implementatiemethoden kunnen variëren, afhankelijk van de talen en kaders die je gebruikt. Raadpleeg de [code_challenge](https://datatracker.ietf.org/doc/html/rfc7636#section-4.2) en [code_verifier](https://datatracker.ietf.org/doc/html/rfc7636#section-4.1) spec voor gedetailleerde definities. Als je werkt aan vertrouwelijke client- of server-gerenderde webapplicaties zoals express of nextjs, ga dan direct naar de volgende stap. Voor meer informatie over PKCE en het verschil tussen openbare en vertrouwelijke clients, zie onze [OAuth security recap](https://blog.logto.io/oauth-security-recap). ```ts class PKCE { readonly codeVerifier: string; readonly codeChallenge: string; constructor() { this.codeVerifier = this.generateCodeVerifier(); this.codeChallenge = this.generateCodeChallenge(this.codeVerifier); } /** * Genereert code verifier * * @link [Client Creates a Code Verifier](https://datatracker.ietf.org/doc/html/rfc7636#section-4.1) */ private generateCodeVerifier() { return generateRandomString(); } /** * Bereken de S256 PKCE codeuitdaging voor een willekeurige code verifier en codeert deze in URL-veilige base64 * * @param {String} codeVerifier Code verifier om de S256 codeuitdaging voor te berekenen * @link [Client Creates the Code Challenge](https://datatracker.ietf.org/doc/html/rfc7636#section-4.2) */ private async generateCodeChallenge(codeVerifier: string) { const encodedCodeVerifier = new TextEncoder().encode(codeVerifier); const codeChallenge = new Uint8Array( await crypto.subtle.digest('SHA-256', encodedCodeVerifier) ); } } ``` #### Genereer staat parameter In de autorisatiestroom is de [staat parameter](https://blog.logto.io/oauth-security-recap/#state) een willekeurig gegenereerde waarde die is opgenomen in het autorisatieverzoek dat door de client is verzonden. Het fungeert als een beveiligingsmaatregel om cross-site request forgery (CSRF) aanvallen te voorkomen. ```ts const state = generateRandomString(); ``` #### Bewaar tussentijdse sessie-info Er zijn verschillende parameters die moeten worden bewaard in de opslag voor validatiedoeleinden nadat de gebruiker is geauthenticeerd en teruggeleid naar de clientkant. We gaan een methode implementeren om die tussentijdse parameters naar de opslag op te slaan. ```ts protected async setSignInSession (data: { codeVerifier: string; redirectUri: string; state: string; }) { await this.storage.setItem('signInSession', data); } ``` #### Aanmelden Laten we alles wat hierboven is geïmplementeerd, samenvoegen, een methode definiëren die een URL voor gebruikersaanmelding genereert en de gebruiker omleiden naar de autorisatieserver om te worden geauthenticeerd. ```ts async signIn(redirectUri: string) { const { appId, resources, scopes } = this.logtoConfig; const { authorizationEndpoint } = await this.getOidcConfig(); // Alleen voor publieke clienttoepassingen const pkce = new PKCE(); const state = generateRandomString(); const queryParameters = new URLSearchParams({ client_id: appId, redirect_uri: redirectUri, code_challenge: pkce.codeChallenge, code_challenge_method: 'S256', state, response_type: 'code', prompt: 'consent', scopes: [...reservedScopes, scopes], }); // Voeg alle bronindicatoren toe indien nodig for (const resource of resources ?? []) { urlSearchParameters.append('resource', resource); } const signInUrl = new URL(`${authorizationEndpoint}?${urlSearchParameters.toString()}`); await this.setSignInSession({ redirectUri, state, codeVerifier: pkce.codeVerifier }); navigate(signInUrl); } ``` ### Behandel user sign-in callback In de vorige sectie maakten we een aanmeldmethode die een URL voor gebruikersauthenticatie genereert. Deze URL bevat alle vereiste parameters die nodig zijn om een authenticatiestroom vanuit een client-app te initiëren. De methode leidt de gebruiker om naar de aanmeldingspagina van de autorisatieserver voor authenticatie. Na een succesvolle aanmelding wordt de eindgebruiker teruggeleid naar de redirect_uri locatie die hierboven is verstrekt. Alle benodigde parameters worden in de redirect_uri meegedragen om de volgende tokenuitwisselingsflows te voltooien. #### Extraheer en verifieer de callback-URL Deze validatiestap is uiterst belangrijk om elke vorm van vervalste autorisatiecallback-aanvallen te voorkomen. De callback-URL **MOET** zorgvuldig worden geverifieerd voordat verdere aanvraag voor code-uitwisseling naar de autorisatieserver wordt verzonden. Allereerst moeten we de signInSession gegevens ophalen die we vanuit de app-opslag hebben opgeslagen. ```ts protected async getSignInSession () { session = await this.storage.getItem('signInSession', data); if (!session) { throw Error('Session not found'); } } ``` Verifieer vervolgens de parameters van de callback-URL voordat je het tokenuitwisselingsverzoek verzendt. - Gebruik de eerder opgeslagen `redirectUri` om te verifiëren of de `callbackUri` hetzelfde is als die we naar de autorisatieserver hebben verzonden. - Gebruik de eerder opgeslagen `state` om te verifiëren of de geretourneerde staat hetzelfde is als degene die we naar de autorisatieserver hebben verzonden. - Controleer of er een fout is geretourneerd door de autorisatieserver. - Controleer of het geretourneerde `authorization_code` bestaat. ```ts verifyAndParseCodeFromCallbackUri(callbackUri: string, redirectUri: string, state: string) { const url = new URL(callbackUri) const parameters = url.searchParams; if (!callbackUri.startWith(redirectUri)) { throw new Error('redirect_uri_mismatched') } //Controleer het foutbericht. //Als de authenticatie mislukt, wordt de gebruiker teruggeleid met aangehechte foutparameters const error = parameters.get('error'); const errorDescription = parameters.get('error_description'); if (error || errorDescription) { throw new Error(`${error}:${errorDescription}`) } //Verificatie van de staat const callbackState = parameter.get('state'); if (callbackState !== state) { throw new Error('state_mismatch'); } //Extraheer autorisatiecode const code = parameters.get('code'); if (!code) { throw new Error('authorization_code_not_found') } return code; } ``` #### Stuur het code-uitwisselingsverzoek Als laatste stap van de gebruikersauthenticatiestroom zullen we de geretourneerde `authorization_code` gebruiken om een tokenuitwisselingsverzoek te sturen en de vereiste autorisatietokens te verkrijgen. Voor meer details over de definities van de aanvraagparameters, raadpleeg de [tokenuitwisselingsspecificatie](https://datatracker.ietf.org/doc/html/rfc8693#section-2). - code: de `authorization_code` die we van de callback URI hebben ontvangen. - clientId: de applicatie ID. - redirectUri: Dezelfde waarde die wordt gebruikt bij het genereren van de aanmeldings-URL voor de gebruiker. - codeVerifier: PKCE code verifier. Net als de redirectUri, vergelijkt de autorisatieserver deze waarde met degene die we eerder hebben verzonden, wat de validatie van het binnenkomende tokenuitwisselingsverzoek waarborgt. ```ts const getTokenByAuthorizationCode = async (payload: { code: string; clientId: string; tokenEndpoint: string; redirectUri: string; codeVerifier: string; }) => { const parameters = new URLSearchParams({ client_id: payload.clientId, code: payload.code, code_verifier: payload.codeVerifier, redirect_uri: payload.redirectUri, grant_type: 'authorization_code', }); return fetch(tokenEndpoint, { method: 'POST', headers: { 'Content-Type': 'application/x-www-form-urlencoded' } body: parameters, }); } ``` #### Behandel sign-in callback Laten we alles wat we hebben samengebracht afronden. Laten we de signInCallback afhandelingsmethode bouwen: ```ts private async saveTokens({refreshToken, idToken, accessToken}) { this.storage.setItem('refreshToken', refreshToken); this.storage.setItem('idToken', idToken); // ondoorzichtig toegangstoken zonder specificatie van de bronindicator this.accessTokenMap.setItem('', accessToken) } async handleSignInCallback(callbackUri: string){ const signInSession = await this.getSignInSession(); if (!signInSession) { throw new Error('sign_in_session.not_found'); } const { redirectUri, state, codeVerifier } = signInSession; const code = verifyAndParseCodeFromCallbackUri(callbackUri, redirectUri, state); const { appId } = this.logtoConfig; const { tokenEndpoint } = await this.getOidcConfig(); const response = await getTokenByAuthorizationCode({ code, clientId: appId, tokenEndpoint, redirectUri, codeVerifier, }); await this.saveTokens(response); } ``` Als resultaat zal het tokenuitwisselingsverzoek de volgende tokens teruggeven: - `id_token`: OIDC idToken, een JSON Web Token (JWT) dat identiteitsinformatie bevat over de geauthenticeerde gebruiker. id_token kan ook worden gebruikt als de Single Source of Truth (SSOT) van de authenticatiestatus van een gebruiker. - `access_token`: De standaard autorisatiecode die wordt geretourneerd door de autorisatieserver. Kan worden gebruikt om het gebruikersinformatie-eindpunt aan te roepen en geauthenticeerde gebruikersinformatie op te halen. - `refresh_token`: (indien offline_access scope aanwezig in het autorisatieverzoek): Dit vernieuwtoken stelt de client-applicatie in staat om een nieuw toegangstoken te verkrijgen zonder dat de gebruiker opnieuw hoeft te authentiseren, waardoor langduriger toegang tot de bronnen wordt verleend. - `expires_in`: De duur van de tijd, in seconden, waarvoor het toegangstoken geldig is voordat het verloopt. ### Verificatie van id_token Het verifiëren en extraheren van claims uit de `id_token` is een cruciale stap in het authenticatieproces om de authenticiteit en integriteit van het token te waarborgen. Hier zijn de belangrijkste stappen die betrokken zijn bij het verifiëren van een `idToken`. - Handtekeningverificatie: De `id_token` is digitaal ondertekend door de autorisatieserver met behulp van zijn privésleutel. De clientapplicatie moet de handtekening verifiëren met de openbare sleutel van de autorisatieserver. Dit verzekert dat het token niet is geknoeid en daadwerkelijk is uitgegeven door de legitieme autorisatieserver. - Uitgever verificatie**:** Controleer of de "iss" (uitgever) claim in de `id_token` overeenkomt met de verwachte waarde, ter bevestiging dat het token is uitgegeven door de juiste autorisatieserver. - Publiek verificatie: Zorg ervoor dat de "aud" (publiek) claim in de `id_token` overeenkomt met de client ID van de clientapplicatie, om ervoor te zorgen dat het token bedoeld is voor de client. - Vervaldatum controle: Controleer of de "iat" (uitgegeven op) claim in de `id_token` niet is verstreken, ter bevestiging dat het token nog steeds geldig is. Aangezien er sprake is van netwerktransactiekosten, moeten we een uitzonderingstijd instellen wanneer we de ontvangen iat-claim valideren. Het geretourneerde id_token is een standaard JSON Web Token (JWT). Afhankelijk van het framework dat je gebruikt, kun je verschillende handige JWT-token validatie plugins vinden om te helpen bij het decoderen en valideren van het token. Voor dit voorbeeld zullen we [jose](https://www.npmjs.com/package/jose) in onze JavaScript SDK gebruiken om token validatie en decodering te vergemakkelijken. ```sh npm install jose ``` ```ts import {createRemoteJWKSet, jwtVerify} from 'jose'; private async getJwksFunction() { const { jwksUri } = await this.getOidcConfig(); return createRemoteJWKSet(new URL(jwksUri))(); } private async verifyIdToken( idToken: string, clientId: string, issuer: string, ) { const jwks = await this.getJwksFunction(); const result = await jwtVerify(idToken, jwks, { audience: clientId, issuer }); if (Math.abs((result.payload.iat ?? 0) - Date.now() / 1000) > issuedAtTimeTolerance) { throw new Error('id_token.invalid_iat'); } return result; }; ``` ### Verkrijg gebruikersinformatie Na succesvolle gebruikersauthenticatie kan basisgebruikersinformatie worden opgehaald uit de OIDC `id_token` die wordt uitgegeven door de autorisatieserver. Echter, vanwege prestatieoverwegingen is de inhoud van het JWT-token beperkt. Om meer gedetailleerde gebruikersprofielinformatie te verkrijgen, bieden OIDC-conforme autorisatieservers een kant-en-klare gebruikersinfo-eindpunt. Dit eindpunt stelt je in staat om aanvullende gebruikersprofielgegevens op te halen door specifieke gebruikersprofielscopes aan te vragen. Bij het oproepen van een tokenuitwisselingseindpunt zonder een specifiek API-bron aan te geven, zal de autorisatieserver standaard een ondoorzichtig type `access_token` afgeven. Dit `access_token` kan alleen worden gebruikt om toegang te krijgen tot het gebruikersinfo-eindpunt, waardoor retrieval van basisgebruikersprofielgegevens mogelijk is. ```ts async getUserInfo() { const { userinfoEndpoint } = await this.getOidcConfig(); const accessToken = await this.getAccessToken(); return fetch(userinfoEndpoint, { headers: { Authorization: `Bearer ${accessToken}` } }); } ``` ### Verkrijg toegangstoken voor beschermde bron autorisatie In de meeste gevallen heeft een clientapplicatie niet alleen gebruikersauthenticatie nodig, maar ook gebruikersautorisatie om toegang te krijgen tot bepaalde beschermde middelen of API-eindpunten. Hier zullen we het `refresh_token` gebruiken dat tijdens het inloggen is verkregen om `access_token(s)` te verkrijgen die specifiek zijn verleend om bepaalde middelen te beheren. Hiermee kunnen we toegang krijgen tot die beschermde API's. Tijdens de gebruikersaanmelding is het cruciaal om alle API-bronindicatoren aan de autorisatieserver te verstrekken. Na succesvolle authenticatie kunnen we alleen de `access_tokens` verkrijgen voor de vooraf geconfigureerde specifieke bronnen. Om dit te bereiken, configureer je vooraf alle vereiste API-bronindicatoren in de configuratie-instellingen van de clientapplicatie voordat je de aanmeldings-URL genereert. ```ts private async getAccessTokenByRefreshToken(resource?:string, scopes?: string[]){ const { appId } = this.logtoConfig; const { tokenEndpoint } = await this.getOidcConfig(); const { refreshToken } = await this.storage.getItem('refreshToken'); const parameters = new URLSearchParams({ 'grant_type': 'refresh_token', 'client_id': appId, 'refresh_token': }); if (resource) { parameters.append('resource', resource); } if (scopes?.length) { parameters.append('scope', scopes.join(' ')); } const response = await fetch(tokenEndpoint, { method: 'POST', grant_type: 'authorization_code', body: parameters, }); // sla en vervang de laatste geretourneerde refreshtoken op await this.storage.setItem('refreshToken', response.refreshToken); await this.accessTokenMap.setItem(`${resource}:${scopes.join(_)}`, response.accessToken); return response.accessToken; } async getAccessToken(resource?:string, scopes?: string[]) { if (!this.idToken) { throw new Error('User not authenticated'); } const accessTokenInStorage = this.accessTokenMap.getItem(`${resource}:${scopes.join(_)}`); if (accessTokenInStorage && accessTokenInStorage.expiresAt > Date.now() / 1000) { return accessToken.token; } return await this.getAccessTokenByRefreshToken(resource, scopes); } ``` ## Samenvatting We hebben essentiële methode implementaties verstrekt voor het gebruikersauthenticatie- en autorisatieproces van de client-side app. Afhankelijk van je specifieke scenario kun je de SDK-logica naar wens organiseren en optimaliseren. Houd er rekening mee dat er variaties kunnen bestaan vanwege verschillende platforms en kaders. Voor aanvullende details, verken de SDK-pakketten die Logto aanbiedt. We moedigen meer gebruikers aan om deel te nemen aan de ontwikkeling en om met ons in discussie te gaan. Je feedback en bijdragen worden zeer gewaardeerd terwijl we de capaciteiten van de SDK blijven verbeteren en uitbreiden. ## Bijlage ### Gereserveerde scopes Door Logto gereserveerde scopes die je moet doorgeven tijdens het initiële authenticatieverzoek. Deze scopes zijn óf OIDC-gereserveerde óf Logto-gereserveerde fundamentele scopes om een succesvolle autorisatiestroom te volbrengen. | Schaalnaam | Beschrijving | | -------------- | --------------------------------------------------------------------------------------------------------------------------------- | | openid | Vereist voor de toekenning van `id_token` na een succesvolle authenticatie. | | offline-access | Vereist voor de toekenning van een `refresh_token` waarmee je clientapplicatie een exchange en een access_token off the screen kan vernieuwen. | | profile | Vereist voor het verkrijgen van toegang tot de basisgebruikersinfo | ### Logto Config | Eigenschapsnaam | Type | Vereist | Beschrijving | Standaardwaarde | | ------------- | ----------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | appId | string | true | De unieke applicatie-identificator. gegenereerd door de autorisatieserver om de client applicatie te identificeren. | | | appSecret | string | | Het applicatiegeheim wordt gebruikt, samen met het applicatie ID, om de identiteit van de aanvrager te verifiëren. Het is vereist voor vertrouwelijke clients zoals Go web of Next.js webapps, en optioneel voor openbare clients zoals native of single-page applicaties (SPA's) | | | endpoint | string | true | Je autorisatieserver basiseindpunt. Deze eigenschap zal op grote schaal worden gebruikt om autorisatieverzoeken te generen. | | | scopes | string list | | Benadrukt alle nodige ressourcetrucs die de gebruiker moet krijgen om toegang te krijgen tot alle gegeven beschermde sources. | [reservedScopes] | | resources | string list | | Alle beschermde bronindicatoren waarvoor de gebruiker toegang kan aanvragen. | | ### Hulpmethoden #### generateRandomString ```ts const generateRandomString = (length = 64) => fromUint8Array(crypto.getRandomValues(new Uint8Array(length)), true); ``` Probeer Logto Cloud vandaag nog