OpenID Connect를 위한 UserInfo 엔드포인트 호출

UserInfo 엔드포인트는 OpenID Connect 인증으로 인증되는 사용자에 대한 청구를 리턴합니다.

이 태스크에 대한 정보

사용자에 대한 청구를 얻으려면 클라이언트는 액세스 토큰을 신임 정보로 사용하여 UserInfo 엔드포인트에 대한 요청을 작성해야 합니다. 액세스 토큰은 OpenID Connect 인증을 통해 얻은 것이어야 합니다. 액세스 토큰이 표시하는 사용자에 대한 청구는 해당 청구에 대한 이름-값 쌍의 콜렉션을 포함하는 JSON 오브젝트로 리턴됩니다. UserInfo 엔드포인트는 OAuth 2.0 보호 자원입니다. 즉, 이 엔드포인트에 액세스하는 데 필요한 신임 정보는 액세스 토큰입니다.

UserInfo 엔드포인트에서 리턴되는 청구는 OpenID Connect 제공자 구성을 사용하여 사용자 정의할 수 있습니다. UserInfo 엔드포인트에서 리턴되는 청구 구성을 참조하십시오.

OpenID Connect가 사용으로 설정된 WebSphere® Application Server traditional 서버에는 다음 URL에서 OpenID Connect UserInfo 엔드포인트에 대한 액세스 권한이 있습니다.
https://server.example.com:443/oidc/endpoint/<provider_name>/userinfo
문제점 방지: 아웃바운드 프록시를 사용하는 경우 OpenID Connect RP는 프록시 호스트를 통해 자동으로 요청을 라우팅하는 수단을 제공하지 않습니다.

OP(OpenID Connect Provider)에 액세스하기 위해 프록시를 사용해야 하는 경우, 임의의 OP 관련 URL 특성에 대해 입력하는 값이 외부 OP 호스트 및 포트가 아니라 프록시 호스트 및 포트를 포함해야 합니다.

대부분의 경우, OP 호스트 및 포트를 프록시 호스트 및 포트로 대체할 수 있습니다. 입력하는 URL이 RP 및 클라이언트(브라우저 또는 애플리케이션) 둘 다에 표시되어야 합니다. 사용할 올바른 URL을 판별하는 방법에 대한 안내가 필요하면 프록시 관리자에게 문의하십시오.

이 예제에서 클라이언트는 SSL 포트가 443으로 설정될 것으로 예상합니다.

프로시저

  1. OpenID Connect 인증을 통해 얻은 액세스 토큰으로 인증을 설정하십시오. 액세스 토큰은 HTTP 기본 권한 부여 헤더에서 제공되거나 access_token 요청 매개변수로 제공될 수 있습니다. 두 경우 모두 액세스 토큰은 인코드될 필요가 없습니다.
  2. GET 또는 POST 요청을 UserInfo 엔드포인트 URL로 전송하십시오.

결과

이러한 단계를 완료한 후에는 예제 절에 나타낸 것처럼 UserInfo 엔드포인트로 전송되는 유효한 HTTP 요청이 있습니다.

올바른 요청의 경우 UserInfo 엔드포인트는 OpenID Connect 제공자에 대해 구성된 청구를 포함하는 application/json 형식의 JSON 오브젝트가 있는 HTTP 200 응답을 리턴합니다.

다음 예제는 유효한 토큰과 유효하지 않은 토큰이 있는 요청을 설명합니다.

  • HTTP Bearer 권한 부여 헤더를 사용하여 액세스 토큰을 전달하는 요청
  • 유효한 액세스 토큰에 대한 응답
  • 유효하지 않은 액세스 토큰
HTTP Bearer 권한 부여 헤더를 사용하여 액세스 토큰을 전달하는 예제 요청:
POST /register HTTP/1.1
Accept: application/x-www-form-urlencoded
Authorization: Bearer fAAdLO1c6QWDbPs9HrWHz5e7nRWVAnxqTTP7i88G
토큰은 access_token 요청 매개변수를 사용하여 전달할 수도 있습니다.
 POST /register HTTP/1.1
 Accept: application/x-www-form-urlencoded
     access_token=fAAdLO1c6QWDbPs9HrWHz5e7nRWVAnxqTTP7i88G

민감한 정보를 포함할 수 있는 HTTP 요청 매개변수가 브라우저 히스토리 또는 캐시에 저장될 수 있으므로 access_token 요청 매개변수 대신 HTTP 권한 부여 헤더를 사용하는 것은 우수 사례입니다.

다음은 유효한 액세스 토큰을 위한 예제 응답입니다. subgroupIds 청구는 항상 리턴됩니다. 여기에 나타낸 다른 청구는 OpenID Connect Provider를 위한 기본 청구입니다.
 HTTP/1.1 200 OK
 Content-Type: application/json
 Cache-Control: no-store
 Pragma: no-cache
{
   "sub"          : "bob",
   "groupIds"     : [ "bobsdepartment","administrators" ], 
   "given_name"   : "Bob",
   "name"         : "Bob Smith",
   "email"        : "bob@mycompany.com",
   "phone_number" : "+1 (604) 555-1234;ext5678",
   "address"      : { "formatted" : "123 Main St., Anytown, TX 77777" },
   "picture"      : "http://mycompany.com/bob_photo.jpg"
}
유효하지 않은 액세스 토큰의 경우, UserInfo 엔드포인트는 WWW-AUTHENTICATE 헤더에 오류 메시지와 함께 HTTP 401 상태 코드를 리턴합니다.
HTTP/1.1 401 Unauthorized
CONTENT-LENGTH : 0
WWW-AUTHENTICATE : Bearer error=invalid_token,       
   error_description=CWWKS1617E: A userinfo request was made with
       an access token that was not recognized. The request URI was
          /oidc/endpoint/MyOAuthProvider/userinfo.