OpenID Connect에서 액세스 토큰 에는 만료 시간이 있습니다. 인증 코드 흐름의 경우 일반적으로 짧은 시간 (예 : 20 분) 후 새로 고침 토큰을 사용하여 새 액세스 토큰을 요청합니다.

토큰 ID 도는 만료 시간을 가지고있다. 내 질문은 이것의 의도는 무엇입니까?

새로 고침 토큰의 만료 시간보다 짧은 ID 토큰 만료 시간은 결국 만료 된 ID 토큰을 가지지 만 유효한 액세스 토큰을 갖게됨을 의미합니다.

그래서 당신은 :

• ID 토큰이 새로 고침 토큰 만료보다 더 오래 만료되도록하거나
• 액세스 토큰과 동일한 만료로 설정하고 만료되면 조치 (무엇?)를 수행합니다.
• 수신시 클라이언트의 ID 토큰을 사용하고 그 이후의 만료 시간을 무시 하시겠습니까?

오픈 ID 연결 사양은 그냥 유효성을 검사 할 때 ID 토큰을 말한다

"The current time MUST be before the time represented by the exp Claim."

(아마도) 위의 세 번째 옵션을 지원합니다.

편집하다

OpenID Connect는 OAuth2를 기반으로 구축되므로 아래의 추가 질문에 대한 답변은 다음과 같은 OAuth2 사양 에서 찾을 수 있습니다 .

expires_in
     RECOMMENDED.  The lifetime in seconds of the access token.

관련 질문은 토큰에 대한 인증 코드를 교환 할 때 다음과 같은 응답을받을 수 있다는 동일한 사양입니다.

{
 "access_token": "SlAV32hkKG",
 "token_type": "Bearer",
 "refresh_token": "8xLOxBtZp8",
 "expires_in": 3600,
 "id_token": "eyJhbG[...]"
}

그러나이 경우 "expires_in"은 무엇과 관련이 있습니까? 액세스 토큰, 새로 고침 토큰 또는 ID 토큰?

(정보를 위해 IdentityServer3 는이를 액세스 토큰 만료 시간으로 설정합니다.)

내 질문에 대한 가정 중 일부가 잘못되었음을 발견 한 내 질문에 대답하고 있습니다. 질문을 다시 작성하는 것보다 여기서 명확히하기가 더 쉽습니다.

ID 토큰은 사용자가 인증했음을 클라이언트에게 증명하고 결과적으로 누구인지를 증명하기위한 것입니다.

클라이언트가 ID 토큰을 받으면 일반적으로이를 ClaimsIdentity로 변환하는 것과 같은 작업을 수행하고이를 유지합니다 (예 : 쿠키 사용).

ID 토큰은이 사용 시점에서 만료되지 않아야합니다 (방금 발급되었으므로 만료되어야 함). 그러나이 후에는 다시 사용 되지 않으므로 사용자가 활성 세션을 유지하는 동안 만료되는지 여부는 중요하지 않습니다 . 클라이언트는 필요한 인증 정보를 가지고 있으며 사용자가 다시 로그인하기 전에 세션이 지속되는 기간에 대한 자체 정책을 선택할 수 있습니다.

질문을 할 때 잘못된 가정은 ID 토큰과 액세스 토큰을 함께 사용해야하므로 둘 다 유효한 만료 날짜가 있어야한다는 것입니다. 이것은 여러 가지 이유로 잘못되었습니다.

• ID 토큰은 클라이언트에 대한 인증 전용입니다 (위에 설명 된대로).
• 액세스 토큰은 클라이언트와 관련이 없습니다. 이들은 리소스에 대한 액세스를위한 것이며 클라이언트는 리소스를 호출해야하는 경우에만 처리합니다.
• 독립형 MVC 또는 WebForms 애플리케이션과 같은 것은 ID 토큰 만 필요합니다. 외부 리소스를 호출하지 않는 경우 액세스 권한을 부여 할 항목이 없으므로 액세스 토큰이 없습니다.

나는 내 이유 때문에 이것을 파고 써야했기 때문에 내가 배운 것을 여기에 게시 할 것이다 ...

먼저, ID 토큰은 신뢰할 수 없으며 현재 시간이 만료 된 시간보다 크면 해당 내용을 무시해야한다는 명백한 위험을 감수하면서 질문에 답할 것입니다. 질문자의 답변에 따르면 사용자의 초기 인증 후에는 ID 토큰이 다시 사용되지 않습니다. 그러나 ID 토큰은 ID 공급자에 의해 서명 되었으므로 앱이 사용하는 다른 서비스에 대해 사용자가 누구인지 확실하게 판단하는 방법을 제공하는 것이 언제든지 유용 할 수 있습니다 . 간단한 사용자 ID 또는 이메일 주소를 사용하는 것은 신뢰할 수 없습니다. 쉽게 스푸핑 될 수 있기 때문에 (누구나 이메일 주소 또는 사용자 ID를 보낼 수 있음) OIDC ID 토큰이 인증 서버 (일반적으로 제 3 자 역할도 함)에 의해 서명 되었기 때문에 스푸핑 될 수 없으며 훨씬 더 안정적인 인증 메커니즘.

예를 들어 모바일 앱은 앱 을 사용 하는 사용자가 누구인지 백엔드 서비스에 알리고 싶을 수 있으며 , ID 토큰이 만료되는 초기 인증 후 짧은 기간 후에이를 수행해야 할 수 있습니다. 따라서 사용자를 안정적으로 인증하는 데 사용할 수 없습니다.

따라서, 단지 인증에 사용되는 토큰 액세스 (같은 - 지정 어떤 권한을 사용자 )을 새로 고칠 수있는 ID 토큰 (인증에 사용- 사용자 지정) 을 새로 고칠 수 있습니까? OIDC 사양에 따르면 대답은 명확하지 않습니다. OIDC / OAuth에는 토큰을 얻기위한 세 가지 "흐름", 인증 코드 흐름, 암시 적 흐름 및 하이브리드 흐름이 있습니다 (다른 두 가지의 변형이므로 아래에서 건너 뛰겠습니다).

OIDC / OAuth 의 암시 적 흐름의 경우 브라우저의 사용자를 권한 부여 끝점으로 리디렉션하고 id_token다음 값을 포함하여 권한 부여 끝점에서 ID 토큰을 요청합니다 .response_type 요청 매개 변수 . 암시 적 흐름 성공적인 인증 응답 을 포함해야합니다 id_token.

들면 인증 코드 플로우 클라이언트 지정 code의 값과 response_type요청 파라미터를 승인 엔드 사용자를 재지시. 성공적인 응답에는 인증 코드가 포함됩니다. 클라이언트 클라이언트는 인증 코드를 사용하여 토큰 엔드 포인트에 요청을하고 OIDC 핵심 섹션 3.1.3.3 성공적인 토큰 응답에 따라 응답에는 ID 토큰이 포함되어야합니다 .

따라서 두 흐름 모두 처음에 ID 토큰을 얻는 방법이지만 어떻게 새로 고치나요? OIDC 섹션 12 : 새로 고침 토큰 사용 에는 새로 고침 토큰 응답에 대한 다음 설명이 있습니다.

새로 고침 토큰이 성공적으로 검증되면 응답 본문은 3.1.3.3 절의 토큰 응답이 됩니다. 단 , id_token이 포함되어 있지 않을 수 있습니다 .

그것은 하지 않을 수도 의 ID 토큰을 포함하고 ID 토큰을 포함하도록 강제 지정 방법이 없기 때문에, 당신은 응답이 ID 토큰을 포함하지 않을 것이라고 가정해야합니다. 따라서 기술적으로 새로 고침 토큰을 사용하여 ID 토큰을 "새로 고침"하는 지정된 방법이 없습니다. 따라서 새 ID 토큰을 얻는 유일한 방법은 사용자를 권한 부여 끝점으로 리디렉션하고 위에서 설명한대로 암시 적 흐름 또는 인증 코드 흐름을 시작하여 사용자를 재 인증 / 인증하는 것 입니다. OIDC 사양은 인증 요청에prompt 요청 매개 변수를 추가 하므로 클라이언트는 인증 서버가 사용자에게 UI를 묻지 않도록 요청할 수 있지만 리디렉션은 계속 발생해야합니다.

이 내용 과 OpenID Connect Core 1.0 사양 에 따라 올바르게 이해 하면 ID 토큰 자체가 세션을 유지하는 메커니즘으로 쿠키에 저장되고 모든 인증이 필요한 요청과 함께 클라이언트에 전송 될 수 있습니다. 그런 다음 클라이언트는 로컬에서 또는 제공 업체의 검증 자 엔드 포인트를 통해 ID 토큰을 확인할 수 있습니다 (제공된 경우 Google과 마찬가지로 ). 토큰이 만료 된 prompt=none경우 URL 매개 변수 에서이 시간을 제외하고는 또 다른 인증 요청을해야합니다 . 또한 id_token_hint매개 변수 에 만료 된 ID 토큰을 보내야합니다 . 그렇지 않으면 공급자가 오류를 반환 할 수 있습니다.

따라서 ID 토큰이 만료되는 것은 당연한 것처럼 보이지만 prompt=none사용자 개입없이 새 ID 토큰을 원활하게 얻을 수 있습니다 (물론 사용자가 해당 OpenID에서 로그 아웃하지 않는 한).

동일한 의도입니다. id_token만료 된 후에는 사용할 수 없습니다 . 주요 차이점은 id_token데이터 구조이며 정보가 토큰 자체에 인코딩되어 있으므로 서버 나 엔드 포인트를 호출 할 필요가 없다는 것입니다. 일반 access_token은 일반적으로 GUID와 같은 불투명 한 아티팩트입니다.

소비자 id_token는 항상 그것의 (시간) 유효성을 확인해야합니다.

나는 IS에 100 % 익숙하지 않지만 편의 분야라고 생각합니다. 항상 exp클레임을 확인해야합니다 .

만료는 유효성 검사 중 하나 일뿐입니다. id_token은 또한 디지털 서명이되어 있으며 이는 반드시 수행 해야하는 유효성 검사 입니다.

토큰 새로 고침은 사용자가 로그인하지 않은 경우에도 인증 서버 (이 경우 OP-OpenID-Connect 공급자)에서 무언가를 요청하는 데 토큰을 다시 사용할 수 있음을 의미합니다. 일반적으로 제한된 리소스에 대해서만 허용되며 사용자가 로그인하고 최소한 한 번 인증 된 후에 만 ​​허용됩니다. 새로 고침 토큰 자체도 시간이 제한되어야합니다.

OIDC 암시 적 흐름 에서 인증 끝점을 호출하고
모든 범위 및 모든 클레임 정보와 함께 응답에서 ID 토큰을받습니다.
이후의 API 호출은 코드 흐름 으로 수행됩니다 .
암시 적 흐름은 자바 스크립트 전용 또는 브라우저 전용 앱을 활성화하기위한 것입니다. 서버와 상호 작용하는 앱이 아닙니다.
따라서이 토큰을 "새로 고침"하는 방법이 있더라도 보안 측면에서 너무 오래 살도록 허용해서는 안됩니다. ID를 가장하는 권한없는 사용자가 도난 당하고 재사용합니다. 이를 위해 새 로그인을 강제해야합니다.

에서 코드 흐름 은 영업의 허가 엔드 포인트를 호출하고, 수신 인증 코드를 (또한 짧은에 대한 인증 토큰, 또는 AUTHCODE라고도 함). 이는 동일한 이유로 암시 적 흐름에서받은 id_token과 유사하게 만료되어야하며 갱신 할 수 없으며 갱신해서는 안됩니다.

그런 다음 UI 또는 앱이 OP의 토큰 엔드 포인트를 호출하고 (때때로 사용자가 UI를 통해 추가로 동의 한 후 OP의 서버에서 소유 한 리소스를 사용할 수 있도록) 두 가지를 모두받습니다.

• 인증을위한 id_token-만료가 더 이상 중요하지 않은 로그 아웃 중 힌트를 제외하고는 서버 호출에서 다시 사용해서는 안됩니다. 따라서 위의 이유로 인해 만료되도록 허용하고 새로 고치지 않아야합니다.
• access_token-나중에 API를 호출 할 때 OP의 UserInfo 엔드 포인트에 제공 될 수 있습니다. 그러면 클레임이 반환되고 API가 그에 따라 승인 할 수 있습니다.

이 access_token은 사용자가 보유한 클레임과 사용자가 제공하기로 동의 한 리소스 (범위 및 각 범위의 클레임별로) 만 API에 알려주기 때문에 새로 고칠 수 있습니다. 위에서 설명한대로 사용자가 더 이상 로그인하지 않은 후에도 액세스를 허용하기위한 것입니다. 물론 로그인하지 않고 가장을 허용하고 싶지 않기 때문에 id_token이 새로 고쳐지는 것을 절대 원하지 않습니다.

이 답변을 댓글로 게시하고 싶었지만 StackOverflow에서별로 활동적이지 않았기 때문에 대체 답변으로 게시하고 있다고 생각합니다.

또한 http://openid.net/specs/openid-connect-session-1_0.html 세션에서 사용자를 로그 아웃 할 때으로 사용 id_token합니다 . 나는 솔직히 특정 사용자를 로그 아웃하는 것에 대해서만 관심이 있기 때문에이 시점에서 만료 되는 것이 정말로 중요하다고 생각하지 않습니다 .id_token_hintid_token

TLDR;

말하는 내용을 신뢰하기 전에 ID 토큰을 확인하십시오.

자세한 내용은

OpenID Connect에서 ID 토큰 만료 시간의 의도는 무엇입니까?

클라이언트가 ID 토큰의 유효성을 검사 할 수 있도록 허용하는 것이 목적이며 클라이언트는 ID 토큰의 정보를 사용하는 작업 전에 ID 토큰의 유효성을 검사 해야합니다 .

에서 오픈 ID 암시 적 흐름 사양 :

이 문서에 정의 된 유효성 검사 절차 중 하나라도 실패하면 올바르게 유효성 검사에 실패한 정보를 필요로하는 모든 작업을 중단해야하며 유효성 검사에 실패한 정보를 사용해서는 안됩니다.

이를 입증하기 위해 Google의 OpenID Connect 문서 는 ID 토큰 유효성 검사에 대해 다음과 같이 말합니다.

ID 토큰을 유용하게 만드는 한 가지는 앱의 여러 구성 요소에 전달할 수 있다는 사실입니다. 이러한 구성 요소는 앱과 사용자를 인증하는 간단한 인증 메커니즘으로 ID 토큰을 사용할 수 있습니다. 그러나 ID 토큰의 정보를 사용하거나이를 사용자가 인증 한 어설 션으로 사용하려면 먼저 유효성을 검사해야합니다.

따라서 클라이언트 애플리케이션이 ID 토큰의 내용을 기반으로 어떤 조치를 취하려면 ID 토큰의 유효성을 다시 확인해야합니다.