[oauth] OAuth 2.0 베어러 토큰은 정확히 무엇입니까?

무기명 토큰
토큰을 소유 한 모든 당사자 ( “소유자”)가 소유 한 다른 당사자가 토큰을 소유 할 수있는 속성을 가진 보안 토큰. 베어러 토큰을 사용하면 베어러가 암호화 키 자료 (소지 증명)를 소유하고 있음을 증명할 필요가 없습니다.

베어러 토큰은 인증 서버에 의해 생성됩니다. 사용자가 애플리케이션 (클라이언트)을 인증하면 인증 서버는 토큰을 생성하여 생성합니다. 베어러 토큰은 OAuth 2.0과 함께 사용되는 주요 유형의 액세스 토큰입니다. 베어러 토큰은 기본적으로 “이 토큰 액세스의 베어러를 제공합니다”라고 말합니다.

베어러 토큰은 일반적으로 인증 서버에 의해 생성 된 일종의 불투명 한 값입니다. 무작위가 아닙니다. 액세스 권한을 부여한 사용자와 클라이언트에게 응용 프로그램 액세스 권한을 기반으로 작성됩니다.

예를 들어 API에 액세스하려면 액세스 토큰을 사용해야합니다. 액세스 토큰은 수명이 짧습니다 (1 시간 정도). 베어러 토큰을 사용하여 새 액세스 토큰을 얻습니다. 액세스 토큰을 받으려면 인증 서버에이 베어러 토큰을 클라이언트 ID와 함께 보냅니다. 이런 식으로 서버는 베어러 토큰을 사용하는 애플리케이션이 베어러 토큰이 작성된 애플리케이션과 동일하다는 것을 알고 있습니다. 예 : 응용 프로그램 용으로 생성 된 베어러 토큰을 가져 와서 내 응용 프로그램과 함께 사용할 수는 없습니다. 응용 프로그램이 생성되지 않았기 때문에 작동하지 않습니다.

Google 새로 고침 토큰은 다음과 같습니다 : 1 / mZ1edKKACtPAb7zGlwSzvs72PvhAbGmB8K1ZrGxpcNM

코멘트에서 복사 : 나는 당신이 제공하는 베어러 토큰에 제한이 없다고 생각합니다. 내가 생각할 수있는 유일한 것은 하나 이상을 허용하는 것이 좋습니다. 예를 들어, 사용자는 애플리케이션을 최대 30 회 인증 할 수 있으며 기존 베어러 토큰은 계속 작동합니다. 그리고 6 개월 동안 사용하지 않았다면 시스템에서 제거 할 것입니다. 인증 서버는 그것들을 생성하고 형식을 정하는 방식에 따라 유효성을 검사해야합니다.

최신 정보:

베어러 토큰은 모든 인라인 조치 HTTP 요청의 Authorization 헤더에 설정됩니다. 예를 들면 다음과 같습니다.

POST /rsvp?eventId=123 HTTP/1.1
Host: events-organizer.com
Authorization: Bearer AbCdEf123456
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0 (KHTML, like Gecko; Gmail Actions)

rsvpStatus=YES

"AbCdEf123456"위 예제 의 문자열 은 베어러 권한 부여 토큰입니다. 인증 서버에서 생성 한 암호화 토큰입니다. 조치와 함께 전송 된 모든 베어러 토큰에는 이슈 필드가 있으며, 대상 필드는 발신자 도메인을 https : // 형식의 URL로 지정합니다. 예를 들어 이메일이 noreply@example.com에서 온 경우 대상은 https://example.com 입니다.

베어러 토큰을 사용하는 경우 요청이 인증 서버에서 전송되고 발신자 도메인을위한 것인지 확인하십시오. 토큰이 확인되지 않으면 서비스는 HTTP 응답 코드 401 (무단)로 요청에 응답해야합니다.

베어러 토큰은 OAuth V2 표준의 일부이며 많은 API에서 널리 채택됩니다.

답변

Authorization: Bearer <access_token>

The syntax for Bearer credentials is as follows:

     b64token    = 1*( ALPHA / DIGIT /
                       "-" / "." / "_" / "~" / "+" / "/" ) *"="
     credentials = "Bearer" 1*SP b64token