Como validar um token de acesso OAuth 2.0 para um servidor de recursos?

Quando um cliente solicita que um servidor de recursos obtenha um recurso protegido com um token de acesso OAuth 2.0, como esse servidor valida o token? O protocolo de token de atualização do OAuth 2.0?

Atualização em novembro de 2015: Conforme Hans Z. abaixo - isso agora é realmente definido como parte da RFC 7662 .

Resposta original: A especificação do OAuth 2.0 ( RFC 6749 ) não define claramente a interação entre um Resource Server (RS) e o Authorization Server (AS) para validação do token de acesso (AT). Realmente depende do formato / estratégia do token do AS - alguns tokens são independentes (como JSON Web Tokens ), enquanto outros podem ser semelhantes a um cookie de sessão, pois apenas referenciam as informações mantidas no servidor no AS.

Houve alguma discussão no Grupo de Trabalho OAuth sobre a criação de uma maneira padrão de um RS se comunicar com a validação do AS for AT. Minha empresa (Ping Identity) criou uma dessas abordagens para o nosso OAuth AS (PingFederate) comercial: https://support.pingidentity.com/s/document-item?bundleId=pingfederate-93&topicId=lzn1564003025072.html#lzn1564003025072__section_N105781001 . Ele usa interação baseada em REST para isso, que é muito complementar ao OAuth 2.0.

Maneira do Google

Validação de token do Google Oauth2

Solicitação:

https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg

Responder:

{
  "audience":"8819981768.apps.googleusercontent.com",
  "user_id":"123456789",
  "scope":"https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email",
  "expires_in":436
} 

Maneira da Microsoft

Microsoft - Oauth2 verifica uma autorização

Maneira do Github

Github - Oauth2 verifica uma autorização

Solicitação:

GET /applications/:client_id/tokens/:access_token

Responder:

{
  "id": 1,
  "url": "https://api.github.com/authorizations/1",
  "scopes": [
    "public_repo"
  ],
  "token": "abc123",
  "app": {
    "url": "http://my-github-app.com",
    "name": "my github app",
    "client_id": "abcde12345fghij67890"
  },
  "note": "optional note",
  "note_url": "http://optional/note/url",
  "updated_at": "2011-09-06T20:39:23Z",
  "created_at": "2011-09-06T17:26:27Z",
  "user": {
    "login": "octocat",
    "id": 1,
    "avatar_url": "https://github.com/images/error/octocat_happy.gif",
    "gravatar_id": "somehexcode",
    "url": "https://api.github.com/users/octocat"
  }
}

Maneira amazônica

Faça login na Amazon - Guia do desenvolvedor (dezembro de 2015, página 21)

Solicitação :

https://api.amazon.com/auth/O2/tokeninfo?access_token=Atza|IQEBLjAsAhRmHjNgHpi0U-Dme37rR6CuUpSR...

Resposta :

HTTP/l.l 200 OK
Date: Fri, 3l May 20l3 23:22:l0 GMT 
x-amzn-RequestId: eb5be423-ca48-lle2-84ad-5775f45l4b09 
Content-Type: application/json 
Content-Length: 247 

{ 
  "iss":"https://www.amazon.com", 
  "user_id": "amznl.account.K2LI23KL2LK2", 
  "aud": "amznl.oa2-client.ASFWDFBRN", 
  "app_id": "amznl.application.436457DFHDH", 
  "exp": 3597, 
  "iat": l3ll280970
}

Uma atualização na resposta de @Scott T.: a interface entre o Resource Server e o Authorization Server para validação de token foi padronizada no IETF RFC 7662 em outubro de 2015, consulte: https://tools.ietf.org/html/rfc7662 . Uma chamada de validação de amostra seria semelhante a:

POST /introspect HTTP/1.1
Host: server.example.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer 23410913-abewfq.123483

token=2YotnFZFEjr1zCsicMWpAA

e uma resposta de amostra:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "active": true,
  "client_id": "l238j323ds-23ij4",
  "username": "jdoe",
  "scope": "read write dolphin",
  "sub": "Z5O3upPC88QrAjx00dis",
  "aud": "https://protected.example.net/resource",
  "iss": "https://server.example.com/",
  "exp": 1419356238,
  "iat": 1419350238,
  "extension_field": "twenty-seven"
}

É claro que a adoção por fornecedores e produtos terá que acontecer com o tempo.

A especificação do OAuth 2.0 não define a peça. Mas pode haver algumas opções:

1. Quando o servidor de recursos obtém o token no cabeçalho Authz, ele chama a API validate / introspect no servidor Authz para validar o token. Aqui, o servidor Authz pode validá-lo usando o DB Store ou verificando a assinatura e certos atributos. Como parte da resposta, ele decodifica o token e envia os dados reais do token junto com o tempo de expiração restante.

2. O Authz Server pode criptografar / assinar o token usando chave privada e, em seguida, publickey / cert pode ser fornecido ao Resource Server. Quando o servidor de recursos obtém o token, ele descriptografa / verifica a assinatura para verificar o token. Retira o conteúdo e processa o token. Em seguida, ele pode fornecer acesso ou rejeitar.

As especificações do OAuth v2 indicam:

Os atributos do token de acesso e os métodos usados ​​para acessar os recursos protegidos estão além do escopo desta especificação e são definidos pelas especificações complementares.

Meu servidor de autorização tem um ponto de extremidade de serviço da web (SOAP) que permite ao servidor de recursos saber se o access_token é válido.