교차 도메인 인증을 위해 JWT를 사용하는 싱글 사인온 플로우

Json Web Token인증을 위해 JWT ( )를 사용하는 방법에 대한 많은 정보가 웹에 있습니다. 그러나 다중 도메인 환경에서 싱글 사인온 솔루션에 JWT 토큰을 사용할 때 흐름이 무엇인지에 대한 명확한 설명을 찾지 못했습니다 .

저는 다른 호스트에 사이트가 많은 회사에서 일합니다. example1.com 및 example2.com을 사용하겠습니다 . 싱글 사인온 솔루션이 필요합니다. 즉, 사용자가 example1.com 에서 인증하면 example2.com 에서도 자동으로 인증되기를 원합니다 .

OpenId Connect 흐름을 사용하여 example1.com 에서 인증하려는 사용자 가 먼저 인증 서버 (또는 OP"OpenId Provider") 로 리디렉션 된다는 것을 이해합니다 . 사용자는 해당 서버에서 인증 한 다음 서명 된 JWT 토큰 을 사용하여 원래 example1.com 사이트로 리디렉션합니다 . ( 나중에 실제 JWT 토큰으로 자체적으로 교환 할 수 있는 중간 토큰 을 반환하는 또 다른 흐름이 있다는 것을 이해 하지만 이것이 우리에게 필요하다고 생각하지 않습니다) ...

이제 사용자는 example1.com 으로 돌아와 인증 을 받았습니다 ! 그는 Authentication헤더에 JWT 토큰을 전달하여 요청을 할 수 있으며 서버는 서명 된 JWT를 확인할 수 있으므로 사용자를 식별 할 수 있습니다. 좋은!

첫 번째 질문 :

JWT 토큰을 클라이언트에 어떻게 저장해야합니까? 다시 말하지만 이것에 대한 많은 정보가 있으며 사람들은 사용 Web Storage이 오래된 것보다 갈 길이 라는 데 동의하는 것 같습니다 cookies. 우리는 브라우저가 다시 시작될 그래서 사용을 할 사이에 JWT가 지속되고 싶어 Local Storage하지 Session Storage...

이제 사용자는 브라우저를 다시 시작할 수 있으며 JWT 토큰이 만료되지 않는 한 example1.com 에서 계속 인증됩니다 !

또한 example1.com 이 다른 도메인에 Ajax 요청을해야하는 경우 CORS를 구성 하면이를 허용한다는 것을 이해합니다 . 그러나 우리의 주요 사용 사례는 교차 도메인 요청이 아니라 단일 사인온 솔루션을 가지고 있습니다 !

따라서 주요 질문 :

이제 사용자가 example2.com으로 이동하여 이미 가지고있는 JWT 토큰을 사용하여 인증을 받으려면 흐름은 어떻게되어야 할까요? Local Storage도메인 간 액세스를 허용하지 않는 것 같으므로이 시점에서 브라우저는 example2.com에 요청하기 위해 JWT 토큰을 읽을 수 없습니다 !

해야 :

• 사용자가 다시 인증 서버 로 리디렉션 됩니까? 사용자가 example1.com 에 대해 인증 되면 인증 서버 가 사용자에게 쿠키를 설정했을 수 있으므로 example2.com에 대한이 새로운 인증 요청은 해당 쿠키를 사용하여 사용자가 이미 인증되었음을 확인하고 즉시 example2.com으로 다시 리디렉션 할 수 있습니다. 동일한 JWT 토큰으로?
• 또는 example2.com 의 브라우저 가 인증 서버로 다시 이동하지 않고도 JWT 토큰에 액세스 할 수 있습니까? 나는 거기에 참조 크로스 스토리지 솔루션은 , 그러나 그 널리 사용된다? 교차 도메인 SSO 환경에 제안 된 솔루션입니까?

우리는 화려한 것을 원하지 않습니다. 주로 사용되는 솔루션에 만족할 것입니다!

사용자는 다시 인증 서버로 리디렉션되고 특히 example2.com을 대상으로하는 새 토큰 (JWT)을 가져와야합니다. 이것이 OpenID Connect 및 기타 교차 도메인 연합 SSO 프로토콜이 작동하는 방식입니다.

사용자가 로그인하지 않고 자격 증명을 요청하고 새 인증 토큰을 발급 할 때 사용자를 중앙 인증 서비스로 리디렉션하는 것은 oauth2 또는 OpenId Connect와 같은 잘 알려진 프로토콜을 사용하는 Single Sign On 시스템의 일반적인 시나리오입니다.

그러나이 스키마가 여러 도메인에서 사용될 때 가장 큰 단점은 사용자가 동일한 출처 정책으로 인해 다른 도메인으로 이동할 때마다 리디렉션되고 인증된다는 것입니다 . 액세스 토큰은 도메인간에 공유 될 example2.com수 없습니다 ( 데이터에 액세스 할 수 없음). of example1.com), 따라서 대상 도메인은 사용자를 인증되지 않은 것으로 간주하여 중앙 SSO 서비스로 리디렉션합니다.

인증 서비스가 자격 증명을 다시 요청하는 것을 방지하기 위해 일반적으로 세션 쿠키 (액세스 토큰이 아님)가 있지만 브라우저 localStorage / 쿠키 및 중간 도메인을 가리키는 iframe을 사용하여 도메인간에 데이터를 공유하는 기술이 있습니다. sso.example.com

1. 에서 사용자를 인증하려면 사용자 example1.com를의 인증 서버로 리디렉션하고 인증 sso.example.com후 JWT를 발급 한 다음이 도메인의 localStorage에 저장합니다. 그런 다음 사용자를 원본 도메인 example1.com으로 리디렉션합니다.

2. 를 example2.com가리키는 iframe을 만듭니다 sso.example.com. sso.example.com의 iframe은 JWT 토큰을 읽고 상위 페이지에 메시지를 보냅니다.

3. 상위 페이지는 메시지를 수신하고 SSO 흐름을 계속하는 첨부 된 토큰을 가져옵니다.

동일 출처 정책 sso.example.com은 localStorage에 접근 할 수 있고 출처와 대상 도메인이 서로를 인식하면 iframe과 상위 페이지 간의 통신이 허용 되기 때문에 문제가 없습니다 ( http://blog.teamtreehouse.com/cross-domain- 참조). messaging-with-postmessage )

개발을 단순화하기 위해 최근 https://github.com/Aralink/ssojwt 에서 JWT와 교차 도메인 SSO를 출시했습니다.

이 방법은 SSO 흐름과 완벽하게 호환됩니다. 리디렉션없이 인증 토큰을 공유하고 도메인이 페더레이션 될 때 불필요한 로그인을 방지하는 방법 일뿐입니다.

이것이 질문에 대한 대답인지 확실하지 않지만 주요 목표가 싱글 사인온 인 경우 간단한 역방향 프록시 가 문제를 해결할 것이라고 생각합니다 (적어도 도메인 간 스토리지).

그래서 example1.com example2.com

뭔가 될 것입니다

example.com/example1

example.com/example2

(그리고 사용자 측에서 이것은 일반적으로 더 깨끗합니다)

이것이 옵션이 아닌 경우 사용자가 1 개의 도메인에서 인증 할 때 AJAX / 숨겨진 iframe을 사용하여 다른 도메인에 대한 인증도 생성하도록 설정해야 할 수 있습니다 (필요한 경우 url을 통해 1 시간 토큰 전송). ).

그리고 이것이 옵션이 아닌 경우 브라우저가 도메인 간 상호 작용에 대해 더 엄격 해지고 있으므로 사용자 이름 + 핀에 의존해야 할 수도 있습니다.