## Johdanto [Logto](https://logto.io/) tarjoaa kehittäjillemme ja liikeryhmillemme kattavan asiakasidentiteetin ja pääsynhallintaratkaisun (CIAM). Tarjoamme laajan valikoiman käyttövalmiita SDK:ita eri alustoille ja sovelluskehyksille. Yhdistämällä Logto-pilvipalvelumme voit vaivattomasti luoda erittäin turvallisen käyttäjän valtuutusprosessin sovellukseesi muutamassa minuutissa. Logto on kehittäjäyhteisöstä lähtöisin oleva yritys, joka arvostaa yhteisömme osallistumista ja panosta. Lisäksi virallisesti kehitettyihin Logto SDK:ihin kannustamme ja toivotamme lämpimästi tervetulleiksi yhteisön kehittäjät jakamaan asiantuntemustaan ja tuomaan monipuolisempia ja käyttäjäystävällisempiä SDK:ita, jotka vastaavat erityyppisten alustojen ja kehysten tarpeita. Tässä artikkelissa näytämme lyhyesti, kuinka OIDC-standardiin perustuva valtuutus-SDK toteutetaan vaihe vaiheelta. Luo sovelluksesi Logtossa ## Yhteys OpenID Connect (OIDC) -virtaus on autentikointiprotokolla, joka perustuu OAuth 2.0 -kehykseen tarjotakseen identiteetin todentamisen ja kertakirjautumisen ominaisuuksia. Sen avulla käyttäjät voivat todennella itsensä sovelluksessa ja saada valtuutuksen pääsyyn yksityisiin resursseihin turvallisesti. Katso lisätietoja OIDC-määrityksistä. ### Työnkulku Vakiomuotoinen valtuutuskoodin virtaus sisältää seuraavat vaiheet: ```mermaid sequenceDiagram actor user as Loppukäyttäjä participant app as Asiakassovellus participant server as Valtuutuspalvelin participant resource as Yksityiset resurssit user ->> app: anonyymi vierailijan kirjautuminen app ->> server: lähetä todennuspyyntö server -->> user: ohjaa käyttäjä kirjautumissivulle user ->> server: kirjautuu sisään tunnuksilla server -->> app: ohjaa takaisin asiakassovellukseen valtuutuskoodilla app ->> server: tokenin vaihtopyyntö valtuutuskoodilla server ->> app: myönnä id_token, access_token ja refresh_token app -->> user: valtuutettu app ->> resource: yksityinen api-pyyntö access_tokenilla resource --> server: synkronoi allekirjoitusavain resource -->> resource: token-tarkistus resource ->> app: 200 OK ``` #### Todennusvirtaus 1. **Käyttäjä aloittaa kirjautumispyynnön:** Anonyymi käyttäjä tulee sovellukseesi julkisesta sisäänkäynnistä. Hän yrittää saada todentamista ja mahdollisesti pyytää pääsyä suojattuun resurssiin kolmannen osapuolen sovelluksessa tai palvelussa. 2. **Käyttäjän todennus:** Asiakassovellus luo todennus-URI:n ja lähettää pyynnön valvontapalvelimelle, joka ohjaa käyttäjän sen kirjautumissivulle. Käyttäjä toimii kirjautumissivun kautta useilla eri kirjautumistavoilla ja valtuutuspalvelin valtuuttaa hänet. 3. **Käsittele kirjautumispalautus:** Onnistuneen todennuksen jälkeen käyttäjä ohjataan takaisin sovellukseesi myönnetyn `authorization_code` -koodin kanssa. Tämä `authorization_code` sisältää kaikki relevantit todennustilaan ja pyydettyyn valtuutukseen liittyvät oikeudet. 4. **Tokenin vaihto:** Pyydä tokenin vaihtoa käyttämällä yllä olevasta palautusosoitteesta poimitun `authorization_code`:n avulla. Vastauksena: - `id_token`: Digitaalisesti allekirjoitettu JWT, joka sisältää identiteettitietoja todennetusta käyttäjästä. - `access_token`: Opaque `access_token`, jota voidaan käyttää käyttäjän perusinfon päätepisteen saavuttamiseksi. - `refresh_token`: Tunnistetoken, joka antaa käyttäjälle mahdollisuuden ylläpitää jatkuvan vaihdon `access_token`:iin. #### Valtuutusvirtaus 1. **Käyttäjätietojen käyttö:** Lisäkäyttäjätietojen saamiseksi sovellus voi tehdä lisäpyyntöjä UserInfo-päätepisteeseen käyttäen opakista `access_token`-tokenia, joka on saatu alun perin tokeninvaihtovirrassa. Näin voidaan saada lisätietoja käyttäjästä, kuten hänen sähköpostiosoitteensa tai profiilikuvansa. 2. **Pääsy suojattuun resurssiin:** Tarvittaessa sovellus voi tehdä lisäpyyntöjä tokeninvaihtopäätepisteelle käyttäen `refresh_token`:ia yhdistettynä `resource`- ja `scope`-parametreihin saadakseen erityisen `access_token`:in, jotta käyttäjä pääsee kohderesurssiin. Tämä prosessi johtaa JWT-muodostetun `access_token`:in myöntämiseen, joka sisältää kaikki tarvittavat valtuutustiedot suojatun resurssin saavuttamiseksi. ## Toteutus Seuraamme joitakin suunnittelustrategioita @logto/client JavaScript SDK:ssa osoittaaksemme prosessin yksinkertaisen SDK:n toteuttamiseen omalle asiakassovelluksellesi. Huomioithan, että yksityiskohtainen koodirakenne saattaa erota käyttämäsi asiakassovelluskehyksen mukaan. Voit vapaasti valita minkä tahansa virallisista Logto SDK:ista esimerkkinä omaan SDK-projektiisi. ### Esikatselu ```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[]) {} } ``` ### Konstruktori Konstruktorin tulisi ottaa [logtoConfig](#logto-config) syötönään. Tämä tarjoaa kaikki tarvittavat määritykset, joita tarvitset auth-yhteyden luomiseen tämän SDK:n kautta. Riippuen käyttämäsi SDK:n alustasta tai kehyksestä, voit antaa konstruktorille pysyvän paikallisen säilytysinstanssin. Tätä säilytysinstanssia käytetään kaikkien valtuutukseen liittyvien tokenien ja salaisuuksien tallentamiseen. ```ts class LogtoClient { constructor(logtoConfig: LogtoConfig, storage: Storage) {} } ``` ### Käyttäjäautentikoinnin alustus Ennen kuin luodaan todennuspyyntö-URL, on välttämätöntä suorittaa useita valmisteluvaiheita turvallisen prosessin varmistamiseksi. #### Saavuta OIDC-määritykset valvontapalvelimelta Määrittele yksityinen metodi `getOidcConfigs`, joka hakee OIDC-määrityksiä valvontapalvelimen hakuosoitteesta. OIDC-määritysten vastaus sisältää kaiken metadatainformaation, jota asiakas voi käyttää kommunikoidessaan valvontapalvelimen kanssa, mukaan lukien sen päätepisteiden sijainnit ja palvelimen ominaisuudet. (Katso [OAuth Valtuutuspalvelimen Metadata Specs](https://datatracker.ietf.org/doc/html/rfc8414) saadaksesi lisää tietoja.) ```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 Generaattori PKCE:n (Proof Key for Code Exchange) [PKCE](https://datatracker.ietf.org/doc/html/rfc7636) validointivirtaus on välttämätöntä kaikille yleisten asiakassovellusten valtuutuskoodinvaihtovirroille. Se vähentää valtuustus-koodin sieppausriskin. Näin ollen "code_challenge" ja "code_verifier" tarvitaan kaikissa julkisten asiakassovellusten (esim. natiivi sovellus ja SPA) valtuutuspyynnöissä. Toteutusmenetelmät vaihtelevat käyttämiesi kielten ja kehysten mukaan. Katso lisätiedot [code_challenge](https://datatracker.ietf.org/doc/html/rfc7636#section-4.2) ja [code_verifier](https://datatracker.ietf.org/doc/html/rfc7636#section-4.1) määräyksistä. Jos työskentelet luottamuksellisella asiakkaalla tai palvelinpuoleisesti renderöidyllä verkkosovelluksella, kuten express tai nextjs, siirry suoraan seuraavaan vaiheeseen. Lisätietoja PKCE:stä ja eroista julkisten ja luottamuksellisten asiakkaiden välillä löydät [OAuth turvallisuus yhteenveto](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); } /** * Generoi koodivarmistajan * * @link [Asiakas luo koodivarmistajan](https://datatracker.ietf.org/doc/html/rfc7636#section-4.1) */ private generateCodeVerifier() { return generateRandomString(); } /** * Laskee S256 PKCE-koodin haasteen satunnaiselle koodin varmistajalle ja koodaa sen URL-turvalliseen base64-muotoon * * @param {String} codeVerifier Koodivarmistaja, jolle lasketaan S256-koodin haaste * @link [Asiakas luo koodin haasteen](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) ); } } ``` #### Generoi tilaparametri Valtuutusprosessissa [tilaparametri](https://blog.logto.io/oauth-security-recap/#state) on satunnaisesti tuotettu arvo, joka sisällytetään todennuspyyntöön, jonka asiakas lähettää. Se toimii turvatoimenpiteenä estämään CSRF-hyökkäykset (ristiinsivustojen pyyntöväärentäminen). ```ts const state = generateRandomString(); ``` #### Väliprosessitietojen tallentaminen On olemassa useita parametreja, jotka on säilytettävä tallennuksessa todentamis- ja palautusprosessin jälkeen. Aiomme toteuttaa menetelmän, jolla asetamme nämä väliprosessiparametrit tallennukseen. ```ts protected async setSignInSession (data: { codeVerifier: string; redirectUri: string; state: string; }) { await this.storage.setItem('signInSession', data); } ``` #### Kirjautuminen Yhteenvetona kaikesta edellä, määrittele menetelmä, joka luo käyttäjän kirjautumis-URL:n ja ohjaa käyttäjän valvontapalvelimelle todennusta varten. ```ts async signIn(redirectUri: string) { const { appId, resources, scopes } = this.logtoConfig; const { authorizationEndpoint } = await this.getOidcConfig(); // Vain julkiset asiakassovellukset 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], }); // Lisää kaikki resurssi-indikaattorit, jos niitä on 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); } ``` ### Käsittele käyttäjän kirjautumispalautus Edellisessä osiossa loimme kirjautumismenetelmän, joka luo URL:n käyttäjätodennusta varten. Tämä URL sisältää kaikki tarvittavat parametrit, jotka ovat tarpeen todennusprosessin aloittamiseksi asiakassovelluksesta. Menetelmä ohjaa käyttäjän valvontapalvelimen kirjautumissivulle todennusta varten. Onnistuneen kirjautumisen jälkeen loppukäyttäjä ohjataan takaisin yllä ilmoitettuun redirect_uri-sijaintiin. Kaikki tarvittavat parametrit kulkevat redirect_uri:ssa seuraavan tokeninvaihtovirran suorittamiseksi. #### Palautus-URL:n poimiminen ja tarkistaminen Tämä validointivaihe on erittäin tärkeä estääkseen minkäänlaisia väärennettyjä valtuutuspaluuhyökkäyksiä. Palautus-URL **TÄYTYY** tarkistaa huolellisesti ennen valtuutuspaluunpyynnön lähettämistä valvontapalvelimelle. Ensinnäkin meidän on haettava sovellustallennukseen tallennetut signInSession-tiedot. ```ts protected async getSignInSession () { session = await this.storage.getItem('signInSession', data); if (!session) { throw Error('Session not found'); } } ``` Tarkista sitten palautus-URL:n parametrit ennen tokeninvaihtopyynnön lähettämistä. - Käytä aiemmin tallennettua `redirectUri`:ta selvittääksesi, onko `callbackUri` sama kuin se, jonka lähetimme valvontapalvelimelle. - Käytä aiemmin tallennettua `state`:a selvittääksesi, onko palautettu tila sama kuin se, jonka lähetimme valvontapalvelimelle. - Tarkista, onko valvontapalvelin palauttanut virheen - Tarkista palautetun `authorization_code`:n olemassaolo ```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') } //Tarkista virhesanoma. // Jos todennus epäonnistuu, käyttäjä ohjataan takaisin kiinnitettyjen virheparametrien kanssa const error = parameters.get('error'); const errorDescription = parameters.get('error_description'); if (error || errorDescription) { throw new Error(`${error}:${errorDescription}`) } // Tilavarmistus const callbackState = parameter.get('state'); if (callbackState !== state) { throw new Error('state_mismatch'); } // Erityskoodin erottelu const code = parameters.get('code'); if (!code) { throw new Error('authorization_code_not_found') } return code; } ``` #### Lähetä koodinvaihtopyyntö Käyttäjän todennusprosessin viimeisessä vaiheessa käytämme palautettua `authorization_code`:a lähettääksemme tokeninvaihtopyynnön ja saadaksemme tarvittavat valtuutustokenit. Katso tarkemmat määritykset pyyntöhallinta-arvoihin [tokeninvaihtomäärityksistä](https://datatracker.ietf.org/doc/html/rfc8693#section-2). - code: saatu `authorization_code` palautus-URI:sta - clientId: sovelluksen ID - redirectUri: sama arvo käytetään, kun generoidaan kirjautumis-URL käyttäjälle. - codeVerifier: PKCE-koodivarmistaja. Vastaavasti redirectUri:n, valvontapalvelin vertaa tätä arvoa aiemmin lähettämäämme arvoon varmistaakseen saapuvan tokeninvaihtopyynnön validoinnin. ```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, }); } ``` #### Käsittele kirjautumispalautus Kootaan kaikki edellä oleva. Rakennetaan signInCallback-käsittelymetodi: ```ts private async saveTokens({refreshToken, idToken, accessToken}) { this.storage.setItem('refreshToken', refreshToken); this.storage.setItem('idToken', idToken); // opakista aiemmin spesifioimaton access token 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 } = tämän.logtoConfig; const { tokenEndpoint } = await this.getOidcConfig(); const response = await getTokenByAuthorizationCode({ code, clientId: appId, tokenEndpoint, redirectUri, codeVerifier, }); await this.saveTokens(response); } ``` Seurauksena on, että tokeninvaihtopyyntö palauttaa seuraavat tokenit: - `id_token`: OIDC idToken, JSON Web Token (JWT), joka sisältää todennetun käyttäjän identiteettitietoja. id_token voidaan myös käyttää käyttäjän todennustilan todistuslähteenä (SSOT). - `access_token`: Oletusaika, jonka valvontapalvelin palauttaa. Sitä voidaan käyttää käyttäjäinfon päätepisteen pyynnön tekemiseen ja todennettujen käyttäjätietojen hakemiseen. - `refresh_token`: (jos offline_access-tila on läsnä valtuutuspyynnössä): tämä refresh-token mahdollistaa asiakassovellukselle uuden access tokenin hankkimisen ilman, että käyttäjän tarvitsee uudelleen kirjautua sisään, mikä antaa pidemmän aikavälin pääsyn resursseihin. - `expires_in`: Keston, sekunteina, jonka ajan access token on voimassa ennen kuin se vanhenee. ### ID-tokenin tarkistus `id_token`-tokenin tarkistaminen ja vaatimusten poimiminen on ratkaiseva vaihe todennusprosessissa tokenin aitouden ja eheyden varmistamiseksi. Tässä ovat tärkeimmät vaiheet `idToken`:in tarkistamisessa. - Allekirjoituksen tarkistus: `id_token` on valvontapalvelimen yksityisellä avaimella digitaalisesti allekirjoitettu. Asiakassovelluksen täytyy tarkistaa allekirjoitus valvontapalvelimen julkisella avaimella. Tämä varmistaa, ettei tokenia ole muokattu ja että se on todellakin laillisen valvontapalvelimen antama. - Liikkeellelaskijan tarkastus**:** Tarkista, että "iss" (liikkeellelaskija) vaade `id_token`:issa vastaa odotettavissa olemaa arvoa, joka ilmaisee, että token on valvontapalvelimen myöntämä. - Yleisön tarkastus: Varmista, että "aud" (yleisö) vaade `id_token`:issa vastaa asiakasohjelman asiakas ID:tä, jolloin varmistetaan, että token on tarkoitettu asiakkaalle - Vanhenemisen tarkastus: Tarkista, ettei "iat" (annettu) vaade `id_token`:issa ole kulunut ohi nykyisen ajan, varmistaen, että token on yhä voimassa. Koska on olemassa verkon siirtokustannuksia, meidän täytyy asettaa "issued"-ajan toleranssi, kun validoimme vastaanotetun tokenin "iat"-vaatetta. Palautettava id_token on vakiomuotoinen JSON Web Token (JWT). Riippuen käyttämästäsi kehyksestä voit löytää valikoiman käteviä JWT-token-validointilaajennoksia, jotka voivat auttaa koodin dekoodaamisessa ja validoinnissa. Tässä esimerkissä käytämme JavaScript-SDK:ssamme [jose](https://www.npmjs.com/package/jose) helpottamaan tokenin validointia ja dekoodausta. ```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; }; ``` ### Hae käyttäjätiedot Onnistuneen käyttäjän todennuksen jälkeen peruskäyttäjätietoja voidaan saada OIDC `id_token`:sta, joka on annettu valvontapalvelimen toimesta. Suorituskykysyistä johtuen JWT-tokenin sisältö on kuitenkin rajallinen. Lisätietojen käyttäjäprofiilitietojen saamiseksi OIDC-yhteensopivat valvontapalvelimet tarjoavat valmiina käyttäjätieto-päätepisteen. Tämä päätepiste mahdollistaa lisäprofiilitietojen hakemisen pyytämällä erityisiä käyttäjäprofiileja koskevia tilavuusparametreja. Kun kutsutaan tokeninvaihtopäätepistettä osoittamatta tiettyä resurssia, valvontapalvelin myöntää oletuksena opakityyppisen access_tokenin. Tätä access_tokenia voidaan käyttää vain käyttämään käyttäjäinfopäätepistettä, sallien pääsyn peruskäyttäjäprofiilitietoja. ```ts async getUserInfo() { const { userinfoEndpoint } = await this.getOidcConfig(); const accessToken = await this.getAccessToken(); return fetch(userinfoEndpoint, { headers: { Authorization: `Bearer ${accessToken}` } }); } ``` ### Hanki pääsytoken suojatun resurssin valtuutusta varten Useimmissa tapauksissa asiakassovellus ei vain vaadi käyttäjän todennusta vaan tarvitsee myös käyttäjävaltuutusta päästäkseen tiettyihin suojattuihin resursseihin tai API-endpointteihin. Tässä käytämme kirjautumisen yhteydessä saatua `refresh_token`:ia saadaksemme `access_token`:ia, jotka on erityisesti myönnetty tiettyjen resurssien hallinnointiin. Tämä mahdollistaa pääsyn suojattuihin sovellusliittymiin. Käyttäjän kirjautumisen aikana on tärkeää antaa kaikki API-resurssi-ilmaisimet valvontapalvelimelle. Onnistuneen todennuksen jälkeen voimme hakea vain etukäteen määritettyjä resursseja varten `access_tokens`. Tämän saavuttamiseksi esikonfiguroidaan tarvitut API-resurssi-ilmaisimet asiakassovelluksen määritysasetuksissa ennen kirjautumis-URL:n luomista. ```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, }); // tallenna ja korvaa uusin palautettu akanuntokeni 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); } ``` ## Yhteenveto Olemme toimittaneet olennaisia menetelmätoteutuksia asiakassovelluksen käyttäjäntodennukselle ja -valtuutukselle. Riippuen skenaariostasi, voit järjestää ja optimoida SDK-logiikan vastaavasti. Huomaa, että eri alustoilla ja kehyksissä voi esiintyä variaatioita. Tutustu lisätietoihin Logton tarjoamiin SDK-paketteihin. Kannustamme useampia käyttäjiä liittymään kehitykseen ja osallistumaan keskusteluihin kanssamme. Palautteesi ja panoksesi ovat erittäin arvokkaita, kun jatkamme SDK:n kykyjen parantamista ja laajentamista. ## Liite ### Varatut tilat Logto-varatut tilat, jotka sinun on toimitettava ensimmäisen testipyynnön aikana. Nämä tilat ovat joko OIDC-varattuja tai Logto-varattuja perusomistuksia onnistuneeseen valtuutukseen. | Tilavan nimi | Kuvaus | | ------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | openid | Vaaditaan `id_token`:n myöntämiseen onnistuneen todennuksen jälkeen. | | offline-access | Vaaditaan `refresh_token`:n myöntämiseen, jolloin asiakassovelluksen avulla voidaan vaihtaa ja uusia access_token näyttöruudun ulkopuolella. | | profile | Vaaditaan pään pääsyn saamiseksi perustietoihin käyttäjästä | ### Logto Konfigurointi | Ominaisuuden nimi | Tyyppi | Vaadittu | Kuvaus | Oletusarvo | | ------------------- | ------------ | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ | | appId | string | true | Yksilöllinen sovellustunniste. Valvontapalvelimen tuottama, joka tunnistaa asiakassovelluksen. | | | appSecret | string | | Sovelluksen salaisuus, jota käytetään yhdessä sovelluksen ID:n kanssa pyytäjän henkilöllisyyden varmistamiseksi. Se on tarpeen luottamuksellisille asiakkaille kuten Go-verkkosovellukset tai Next.js-verkkosovellukset, ja valinnainen julkisille asiakkaille kuten natiivi- tai yksisivun sovelluksille (SPA) | | | endpoint | string | true | Oma valvontapalvelimesi juuripäätepiste. Tämä ominaisuus käytetään laajalti valtuutuspyyntöjen tuottamiseksi. | | | scopes | string lista | | Ilmaisee kaikki tarvittavat resurssitilat, jotka käyttäjän on annettava pääsyä tiettyihin suojattuihin resursseihin. | [reservedScopes] | | resources | string lista | | Kaikki suojatut resurssitunnisteet, joihin käyttäjä voi pyytää pääsyä. | | ### Aputoiminnot #### generateRandomString ```ts const generateRandomString = (length = 64) => fromUint8Array(crypto.getRandomValues(new Uint8Array(length)), true); ``` Kokeile Logto Cloudia tänään