Scopes, M2M e APIs con server di risorse - Amazon Cognito

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Scopes, M2M e APIs con server di risorse

Dopo aver configurato un dominio per il tuo pool di utenti, Amazon Cognito effettua automaticamente il provisioning di un server di autorizzazione OAuth 2.0 e di un'interfaccia utente Web ospitata con pagine di registrazione e accesso che l'app può presentare ai tuoi utenti. Per ulteriori informazioni, consulta Aggiungi un client di app con l'interfaccia utente ospitata. Puoi scegliere gli ambiti che desideri che il server di autorizzazione aggiunga ai token di accesso. Gli ambiti autorizzano l'accesso ai server di risorse e ai dati degli utenti.

Un server di risorse è un OAuth server 2.0. API Per proteggere le risorse protette dall'accesso, verifica che i token di accesso del pool di utenti contengano gli ambiti che autorizzano il metodo e il percorso richiesti nell'ambito che protegge. API Verifica l'emittente in base alla firma del token, la validità in base alla scadenza del token e il livello di accesso in base agli ambiti delle richieste di token. Gli ambiti del pool di utenti sono indicati nel claim del token di accesso. scope Per ulteriori informazioni sulle dichiarazioni nei token di accesso di Amazon Cognito, consulta Comprendere il token di accesso.

Con Amazon Cognito, gli ambiti dei token di accesso possono autorizzare l'accesso ad attributi esterni APIs o agli attributi utente. Puoi emettere token di accesso a utenti locali, utenti federati o identità di macchine.

APIautorizzazione

Di seguito sono riportati alcuni dei modi in cui puoi autorizzare le richieste APIs con i token Amazon Cognito:

Token di accesso

Quando aggiungi un autorizzatore Amazon Cognito a una configurazione di richiesta di REST API metodo, aggiungi gli ambiti di autorizzazione alla configurazione dell'autorizzatore. Con questa configurazione, API accetti i token di accesso nell'Authorizationintestazione e li esamina per verificare gli ambiti accettati.

Token ID

Quando passi un token ID valido a un autorizzatore di Amazon Cognito nel tuo RESTAPI, API Gateway accetta la richiesta e passa il contenuto del token ID al backend. API

Autorizzazioni verificate da Amazon

In Autorizzazioni verificate, hai la possibilità di creare un API archivio di policy collegato. Verified Permissions crea e assegna un autorizzatore Lambda che elabora ID o token di accesso dall'intestazione della richiesta. Authorization Questo autorizzatore Lambda passa il token all'archivio delle politiche, dove Verified Permissions lo confronta con le politiche e restituisce una decisione di autorizzazione o rifiuto all'autorizzatore.

Machine-to-machine Autorizzazione (M2M)

Amazon Cognito supporta applicazioni che accedono ai API dati con identità di macchina. Le identità delle macchine nei pool di utenti sono client riservati che vengono eseguiti su server di applicazioni e si connettono a reti remote. APIs Il loro funzionamento avviene senza l'interazione dell'utente: attività pianificate, flussi di dati o aggiornamenti delle risorse. Quando questi client autorizzano le proprie richieste con un token di accesso, eseguono l'autorizzazione da macchina a macchina o M2M. Nell'autorizzazione M2M, un segreto condiviso sostituisce le credenziali dell'utente nel controllo degli accessi.

Un'applicazione che accede a un'APIautorizzazione M2M deve avere un ID client e un client secret. Nel tuo pool di utenti, devi creare un client di app che supporti la concessione delle credenziali dei client. Per supportare le credenziali del client, il client dell'app deve disporre di un client secret e devi disporre di un dominio del pool di utenti. In questo flusso, l'identità della macchina richiede un token di accesso direttamente da. Endpoint Token È possibile autorizzare solo ambiti personalizzati dai server di risorse nei token di accesso per la concessione delle credenziali dei client. Per ulteriori informazioni sulla configurazione dei client delle app, consulta. Impostazioni specifiche dell'applicazione con client di app

Il token di accesso derivante dalla concessione delle credenziali di un client è una dichiarazione verificabile delle operazioni che si desidera consentire all'identità della macchina di richiedere a un. API Per saperne di più su come i token di accesso autorizzano API le richieste, continua a leggere. Per un esempio di applicazione, consulta Amazon Cognito e utilizzo dell'autorizzazione da macchina a macchina basata su API Gateway. AWS CDK

L'autorizzazione M2M ha un modello di fatturazione diverso dal modo in cui viene fatturata la fattura agli utenti attivi mensili ()MAUs. Laddove l'autenticazione utente comporta un costo per utente attivo, la fatturazione M2M riflette le credenziali dei clienti attivi, i client delle app e il volume totale delle richieste di token. Per ulteriori informazioni, consultare Prezzi di Amazon Cognito. Per controllare i costi dell'autorizzazione M2M, ottimizza la durata dei token di accesso e il numero di richieste di token effettuate dalle tue applicazioni. Gestione della scadenza e della memorizzazione nella cache dei token del pool di utentiScoprite come utilizzare il caching di API Gateway per ridurre le richieste di nuovi token nell'autorizzazione M2M.

Per informazioni sull'ottimizzazione delle operazioni di Amazon Cognito che aggiungono costi alla bolletta, AWS consulta. Gestione dei costi

Informazioni sugli ambiti

Un ambito è un livello di accesso che un'app può richiedere a una risorsa. In un token di accesso Amazon Cognito, l'ambito è supportato dal trust che configuri con il tuo pool di utenti: un emittente affidabile di token di accesso con una firma digitale nota. I pool di utenti possono generare token di accesso con scopi che dimostrano che il cliente è autorizzato a gestire alcuni o tutti i propri profili utente o a recuperare dati da un back-end. API I pool di utenti di Amazon Cognito emettono token di accesso con l'APIambito riservato, gli ambiti personalizzati e gli ambiti OpenID Connect (). OIDC

L'ambito riservato dei pool di utenti API

L'aws.cognito.signin.user.adminambito autorizza le operazioni self-service per l'utente corrente nei pool di utenti di Amazon Cognito. API Autorizza il titolare di un token di accesso a interrogare e aggiornare tutte le informazioni sul portatore con, ad esempio, le operazioni and. GetUserUpdateUserAttributesAPI Quando autentichi il tuo utente con i API pool di utenti di Amazon Cognito, questo è l'unico ambito che ricevi nel token di accesso. È anche l'unico ambito di cui hai bisogno per leggere e scrivere gli attributi utente che il client dell'app è autorizzato a leggere e scrivere. Puoi anche richiedere questo ambito nelle richieste a Endpoint Authorize. Questo ambito da solo non è sufficiente per richiedere attributi utente da userInfo endpoint. Per i token di accesso che autorizzano sia i pool di utenti che API le userInfo richieste per i tuoi utenti, devi richiedere entrambi gli ambiti openid e in una richiesta. aws.cognito.signin.user.admin /oauth2/authorize

Ambiti personalizzati

Gli ambiti personalizzati autorizzano le richieste verso l'esterno APIs protetto dai server di risorse. Puoi richiedere ambiti personalizzati con altri tipi di ambiti. Puoi trovare maggiori informazioni sugli ambiti personalizzati in questa pagina.

Ambiti OpenID Connect () OIDC

Quando autentichi gli utenti con il server di autorizzazione del pool di utenti, inclusa l'interfaccia utente ospitata, devi richiedere gli ambiti. Puoi autenticare gli utenti locali del pool di utenti e gli utenti federati di terze parti nel tuo server di autorizzazione Amazon Cognito. OIDCgli ambiti autorizzano l'app a leggere le informazioni sugli utenti dal pool userInfo endpoint di utenti. Il OAuth modello, in cui si interrogano gli attributi utente dall'userInfoendpoint, può ottimizzare l'app per un volume elevato di richieste di attributi utente. L'endpoint userInfo restituisce gli attributi a un livello di autorizzazione determinato dagli ambiti del token di accesso. Puoi autorizzare il client dell'app a emettere token di accesso con i seguenti ambiti. OIDC

openid

L'ambito minimo per le query OpenID Connect (OIDC). Autorizza il token ID, l'attestazione di identificazione univoca sub e la possibilità di richiedere altri ambiti.

Nota

Quando richiedi l'ambito openid e nessun altro, il token ID del pool di utenti e la risposta userInfo includono attestazioni per tutti gli attributi utente che il client dell'app è in grado di leggere. Quando richiedi openid e altri OIDC ambiti comeprofile, and emailphone, il contenuto del token ID e della userInforisposta è limitato ai vincoli degli ambiti aggiuntivi.

Ad esempio, una richiesta a Endpoint Authorize con il parametro scope=openid+email restituisce un token ID con sub, email e email_verified. Il token di accesso di questa richiesta restituisce gli stessi attributi dauserInfo endpoint. Una richiesta con parametro scope=openid restituisce tutti gli attributi leggibili dal client nel token ID e da userInfo.

profilo

Autorizza tutti gli attributi utente che il client dell'app è in grado di leggere.

e-mail

Autorizza gli attributi utente email e email_verified. Amazon Cognito restituisce email_verified se un valore è stato impostato in modo esplicito.

telefono

Autorizza gli attributi utente phone_number e phone_number_verified.

Informazioni sui server di risorse

Un server di risorse API potrebbe concedere l'accesso alle informazioni in un database o controllare le tue risorse IT. Un token di accesso Amazon Cognito può autorizzare l'accesso a APIs tale supporto 2.0. OAuth Amazon API Gateway offre REST APIs un supporto integrato per l'autorizzazione con i token di accesso Amazon Cognito. L'app passa il token di accesso contenuto nella API chiamata al server di risorse. Il server di risorse ispeziona il token d'accesso per determinare se gli accessi devono essere concessi.

Amazon Cognito potrebbe apportare future modifiche allo schema dei token di accesso del pool di utenti. Se l'app analizza il contenuto del token di accesso prima di passarlo a un altroAPI, è necessario progettare il codice per accettare gli aggiornamenti dello schema.

Gli ambiti personalizzati vengono definiti dall'utente ed estendono le funzionalità di autorizzazione di un pool di utenti per includere scopi non correlati all'interrogazione e alla modifica degli utenti e dei relativi attributi. Ad esempio, se hai un server di risorse per l'archiviazione di foto, questo potrebbe definire due ambiti, photos.read per l'accesso in lettura alle foto e photos.write per l'accesso in scrittura/eliminazione. Puoi configurarne uno API per accettare i token di accesso per l'autorizzazione e concedere HTTP GET le richieste di accesso ai token con photos.read il scope claim e HTTP POST le richieste ai token con. photos.write Questi sono ambiti personalizzati.

Nota

Per elaborare una qualsiasi richiesta all'interno del token, il tuo server di risorse deve verificare la firma e la data di scadenza dei token d'accesso. Per ulteriori informazioni sulla verifica dei token, consulta Verifica di un token Web JSON. Per ulteriori informazioni sulla verifica e l'utilizzo dei token del pool di utenti in Amazon API Gateway, consulta il blog Integrating Amazon Cognito User Pools with Gateway. API APIGateway è una buona opzione per ispezionare i token di accesso e proteggere le risorse. Per ulteriori informazioni sugli autorizzatori API Gateway Lambda, consulta Utilizzare gli autorizzatori Gateway API Lambda.

Panoramica

Con Amazon Cognito, puoi creare server di risorse OAuth 2.0 e associare ad essi ambiti personalizzati. Gli ambiti personalizzati in un token di accesso autorizzano azioni specifiche nel tuo. API Puoi autorizzare qualsiasi app del client nel pool di utenti a emettere ambiti personalizzati da uno qualsiasi dei server di risorse. Associa gli ambiti personalizzati a un client di app e richiedi tali ambiti nelle concessioni di codice di autorizzazione OAuth 2.0, nelle concessioni implicite e nelle concessioni di credenziali client a. Endpoint Token Amazon Cognito aggiunge ambiti personalizzati nell'attestazione scope in un token di accesso. Un client può utilizzare il token d'accesso piuttosto che il suo server di risorse, facendo in modo che le decisioni legate all'autorizzazione siano basate sugli ambiti presenti nel token. Per ulteriori informazioni sui token d'accesso proposto, consulta Utilizzo dei token con i bacini d'utenza.

Panoramica del flusso di un server di risorse. Il client richiede una concessione con un ambito personalizzato, il pool di utenti restituisce un token di accesso con l'ambito personalizzato e il client presenta il token di accesso a un. API

Per ottenere un token di accesso con ambiti personalizzati, l'app deve effettuare una richiesta all'Endpoint Token per riscattare un codice di autorizzazione o per richiedere la concessione delle credenziali del client. Nell'interfaccia utente ospitata, puoi anche richiedere ambiti personalizzati in un token di accesso da una concessione implicita.

Nota

Perché sono progettate per l'autenticazione interattiva con il pool di utenti come IdP InitiateAuthe AdminInitiateAuthle richieste producono solo un'scopeattestazione nel token di accesso con il singolo valore. aws.cognito.signin.user.admin

Gestione del server di risorse e degli ambiti personalizzati

Durante la creazione di un server di risorse, è necessario fornire un nome per il server di risorse e un identificatore per il server di risorse. Per ogni ambito che crei nel server di risorse, è necessario fornire nome e descrizione.

  • Nome del server di risorse: un nome intuitivo per il server di risorse, ad esempio Solar system object tracker o Photo API.

  • Identificatore del server di risorse: un identificatore univoco per il server di risorse. L'identificatore è qualsiasi nome che desideri associare al tuoAPI, ad esempio. solar-system-data È possibile configurare identificatori più lunghi, ad esempio https://solar-system-data-api.example.com come riferimento più diretto ai API URI percorsi, ma stringhe più lunghe aumentano la dimensione dei token di accesso.

  • Nome ambito: il valore che desideri nell'attestazione scope. Ad esempio sunproximity.read.

  • Descrizione: una descrizione intuitiva dell'ambito. Ad esempio Check current proximity to sun.

Amazon Cognito può includere ambiti personalizzati nei token di accesso per qualsiasi utente, locale nel pool di utenti o federato, con un provider di identità di terze parti. Puoi scegliere gli ambiti per i token di accesso degli utenti durante i flussi di autenticazione con il server di autorizzazione OAuth 2.0 che include l'interfaccia utente ospitata. L'autenticazione dell'utente deve iniziare in corrispondenza di Endpoint Authorize con scope come uno dei parametri della richiesta. Di seguito è riportato un formato consigliato per i server di risorse. Per un identificatore, usa un nome descrittivo. API Per un ambito personalizzato, usa l'azione che autorizzano.

resourceServerIdentifier/scopeName

Ad esempio, hai scoperto un nuovo asteroide nella fascia di Kuiper e desideri registrarlo tramite il tuo. solar-system-data API L'ambito che autorizza le operazioni di scrittura nel database degli asteroidi è asteroids.add. Quando richiedi il token di accesso che ti autorizzerà a registrare la tua scoperta, formatta il parametro di richiesta come. scope HTTPS scope=solar-system-data/asteroids.add

L'eliminazione di un ambito dal server di risorse non elimina la relativa associazione con tutti i client. Invece, l'ambito è contrassegnato come inattivo. Amazon Cognito non aggiunge ambiti inattivi ai token di accesso, ma per il resto procede normalmente se l'app ne richiede uno. Se aggiungi nuovamente l'ambito al tuo server di risorse in un secondo momento, Amazon Cognito lo scrive nuovamente nel token di accesso. Se richiedi un ambito che non hai associato all'app del client, a prescindere che venga eliminato dal server di risorse del pool di utenti, l'autenticazione non va a buon fine.

È possibile utilizzare AWS Management Console API, o CLI per definire server e ambiti di risorse per il pool di utenti.

Definizione di un server di risorse per il tuo bacino d'utenza (AWS Management Console)

È possibile utilizzare il AWS Management Console per definire un server di risorse per il pool di utenti.

Definizione di un server di risorse
  1. Accedi alla console Amazon Cognito.

  2. Nel riquadro di navigazione, seleziona User Pools (bacini d'utenza) e seleziona i bacini d'utenza che intendi modificare.

  3. Seleziona la scheda App integration (integrazione app) e individua l'opzione Resource servers (server di risorse).

  4. Seleziona Create a resource server (Crea un server di risorse).

  5. Inserisci un nome del server di risorse. Ad esempio Photo Server.

  6. Inserisci un Resource server identifier (identificatore del server di risorse). Ad esempio com.example.photos.

  7. Inserisci gli Custom scopes (ambiti personalizzati) per le risorse, come read e write.

  8. Per ogni Scope name (nome ambito), inserisci una Description (descrizione), come view your photos e update your photos.

  9. Scegli Create (Crea) .

I tuoi ambiti personalizzati possono essere esaminati nella scheda Integrazione app alla voce Resource servers (Server di risorse), nella colonna Custom scopes (ambiti personalizzati). Gli ambiti personalizzati possono essere abilitati per i client app dalla scheda Integrazione app (App integration) alla voce App clients (client dell'App). Seleziona un client dell'App, individua l'opzione Hosted UI settings (impostazioni dell'interfaccia utente ospitata) e seleziona Edit (modifica). Aggiungi degli Custom scopes (ambiti personalizzati) e seleziona Save changes (salva modifiche).

Definizione di un server di risorse per il pool di utenti (AWS CLI e AWS API)

Usa i seguenti comandi per specificare le impostazioni dei server di risorse per il tuo bacino d'utenza.

Creazione di un server di risorse
Ottenimento di informazioni sulle impostazioni dei tuoi server di risorse
Creazione di liste di informazioni su tutti i server di risorse per il tuo bacino d'utenza
Eliminazione di un server di risorse
Aggiornamento delle impostazioni per un server di risorse