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

에 따르면 RFC6750 무기명 토큰 사용, 토큰 (Token) 베어러 : -THE의 OAuth 2.0 인증 프레임 워크 :

토큰을 소유 한 당사자 ( "소지자")가 소유 한 다른 당사자가 토큰을 소유 할 수있는 속성을 가진 보안 토큰.

나 에게이 정의는 모호하며 사양을 찾을 수 없습니다.

• 권한 부여 제공자를 구현한다고 가정하고 베어러 토큰에 어떤 종류의 문자열을 제공 할 수 있습니까?
• 임의의 문자열 일 수 있습니까?
• 일부 속성을 base64로 인코딩해야합니까?
  해시해야합니까?
• 그리고 서비스 공급자가이 토큰의 유효성을 검사하기 위해 인증 공급자를 쿼리해야합니까?

포인터 주셔서 감사합니다.

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

베어러 토큰은 인증 서버에 의해 생성됩니다. 사용자가 애플리케이션 (클라이언트)을 인증하면 인증 서버는 토큰을 생성하여 생성합니다. 베어러 토큰은 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에서 널리 채택됩니다.

귀하의 질문을 읽으면서 Bearer 토큰이 암호화되거나 서명되는 방법을 인터넷에서 검색하지 못했습니다. 베어러 토큰은 해시되지 않았을 것입니다.

그러나 귀하의 질문은 Bearer 토큰 기능에 대한 답변을 찾으려고합니다.

권한 부여 제공자를 구현한다고 가정하고 베어러 토큰에 어떤 종류의 문자열을 제공 할 수 있습니까? 임의의 문자열 일 수 있습니까? 일부 속성의 base64 인코딩이어야합니까? 해시해야합니까?

Bearer 토큰과 Refresh 토큰의 작동 방식을 설명하려고합니다.

사용자가 SSL을 통해 사용자와 비밀번호를 보내는 토큰을 서버에 요청하면 서버는 액세스 토큰 과 새로 고침 토큰의 두 가지를 리턴합니다 .

액세스 토큰은 구체적인 사용자로 인증하기 위해 모든 요청 헤더에 추가해야하는 베어러 토큰입니다.

Authorization: Bearer <access_token>

액세스 토큰은 원하는 모든 사용자 속성, 클레임 및 역할이 포함 된 암호화 된 문자열입니다. 역할이나 클레임을 더 추가하면 토큰 크기가 증가하는지 확인할 수 있습니다. 리소스 서버가 액세스 토큰을 받으면이를 해독하고 이러한 사용자 속성을 읽을 수 있습니다. 이런 식으로 사용자는 모든 응용 프로그램과 함께 유효성이 검사되고 부여됩니다.

액세스 토큰의 만료 기간이 짧습니다 (예 : 30 분). 액세스 토큰의 만료 기간이 길면 이론적으로 취소 할 가능성이 없기 때문에 문제가됩니다. 따라서 "User"로 변경되는 role = "Admin"을 가진 사용자를 상상하십시오. 사용자가 role = "Admin"으로 이전 토큰을 유지하면 관리자 권한으로 토큰이 만료 될 때까지 액세스 할 수 있습니다. 그렇기 때문에 액세스 토큰의 수명이 짧습니다.

그러나 한 가지 문제가 떠 오릅니다. 액세스 토큰의 만료 기간이 짧은 경우 모든 짧은 기간 동안 사용자와 비밀번호를 보내야합니다. 안전한가요? 아닙니다. 우리는 그것을 피해야합니다. 새로 고침 토큰이이 문제를 해결하는 것처럼 보입니다.

새로 고침 토큰은 DB에 저장되며 만료 기간이 길어집니다 (예 : 1 개월).

사용자는 새로 고침 토큰을 사용하여 사용자가 첫 번째 토큰 요청에서 수신 한 새 액세스 토큰 (예 : 30 분마다 만료)을 얻을 수 있습니다. 액세스 토큰이 만료되면 클라이언트는 새로 고침 토큰을 보내야합니다. 이 새로 고침 토큰이 DB에 존재하면 서버는 클라이언트에게 새 액세스 토큰과 다른 새로 고침 토큰을 반환하고 이전 새로 고침 토큰을 새 것으로 교체합니다.

사용자 액세스 토큰이 손상된 경우 해당 사용자의 새로 고침 토큰을 DB에서 삭제해야합니다. 이렇게하면 해커가 새로 고침 토큰을 보내는 새 액세스 토큰을 얻으려고 할 때이 작업이 거부되므로 액세스 토큰이 만료 될 때까지만 토큰이 유효합니다.

무기명 토큰은 알파벳, 숫자, "-", "."의 반복입니다. , "_", "~", "+", "/"뒤에 0 개 이상의 "=".

RFC 6750 2.1. 권한 부여 요청 헤더 필드 (형식은 ABNF (증강 BNF) 임)

The syntax for Bearer credentials is as follows:

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

Base64처럼 보이지만 헤더의 토큰을 base64로 인코딩해야합니까? 그렇지 않습니다.

"HTTP / 1.1, part 7 : Authentication"**으로 조금 더 깊이 파고 들었지만 b64token은 base64, base64url 등에서 일반적으로 사용되는 문자를 허용하는 ABNF 구문 정의 일뿐입니다. 따라서 b64token은 그렇지 않습니다. 인코딩 또는 디코딩을 정의하되 액세스 토큰을 포함 할 권한 부여 헤더 부분에서 사용할 수있는 문자를 정의하십시오.

참고 문헌

• RFC 5234 3.6. 변수 반복 : * 규칙
• RFC 2616 2.1 증강 BNF