한 번의 인증 과정(로그인)으로 여러 컴퓨터 상의 자원을 이용 가능하게 하는 인증 기능
SSO의 장단점
장점
- 사용자 편의성 향상: 사용자는 여러 서비스에 대해 따로 로그인할 필요 없이, 한 번의 로그인으로 모든 서비스를 이용할 수 있습니다. 이는 사용자 경험을 크게 향상시킵니다.
- 비밀번호 관리 간소화: 사용자는 다양한 서비스를 이용하기 위해 여러 비밀번호를 기억하고 관리할 필요가 없습니다. 이는 비밀번호 관리의 부담을 줄여줍니다.
- 보안 강화: 중앙 집중식 인증 시스템을 통해 보안 정책을 일관되게 적용할 수 있습니다. 또한, 사용자가 강력한 단일 비밀번호만 관리하면 되므로 비밀번호 관련 보안 위험을 줄일 수 있습니다.
- 관리 효율성 증가: 조직의 IT 관리자는 사용자 계정을 중앙에서 관리할 수 있으므로, 계정 관리에 대한 효율성이 증가합니다.
단점
- 단일 실패 지점(Single Point of Failure): SSO 시스템이 다운되면 연결된 모든 서비스에 접근할 수 없게 됩니다. 이는 서비스 이용에 큰 차질을 빚을 수 있습니다.
- 보안 취약성: SSO는 강력한 보안 메커니즘이 필요한데, 만약 SSO 시스템이 해킹당하면 연결된 모든 서비스가 위험에 노출될 수 있습니다.
- 구현 복잡성: SSO 시스템을 구축하고 유지 관리하는 것은 복잡하고 비용이 많이 들 수 있습니다. 특히, 다양한 시스템과의 호환성을 확보하는 것이 어려울 수 있습니다.
- 프라이버시 우려: 사용자의 활동이 중앙에서 추적될 수 있으므로, 프라이버시에 대한 우려가 존재합니다. 사용자가 어떤 서비스를 언제 이용했는지에 대한 정보가 중앙에 모일 수 있기 때문입니다.
SSO Process
1. 어플리케이션에서 로그인 -> 앱에서 SSO 토큰 생성 -> SSO 서비스로 인증 요청 보냄
2. 서비스에서 이전에 인증 정보가 있는지 확인 -> 확인 응답 전송 -> 액세스 권한 부여
3. 유효한 인증 정보가 없는 경우
중앙 로그인 시스템으로 리디렉션 -> 이름과 암호 제출 요청 -> 제출하면 인증 정보 확인 후 응답
인증 토큰을 활용한 SSO 구현
토큰
최초 인증을 성공한 사용자에게 일종의 증표로서 인증 서버가 발급하는 정보
- Session(세션) 방식과 다르게 서버가 각각 로그인한 사용자의 세션 정보를 따로 보관하지 않음
- 한 번 인증 토큰이 클라이언트에게 발급되면, 클라이언트는 추후 Request 부터는 해당 토큰을 포함하며,
서버는 클라이언트 Request 에 포함된 토큰을 그때그때 확인하여 인증과정을 거침
- 사용자가 Service 1 에 접속하여 로그인 버튼을 클릭
- Service 1 은 인증서비스(idP:Identity Provider)로 해당 요청을 Redirect 함
- 인증 서비스는 사용자에게 로그인 화면을 제공
- 사용자는 ID,PW (혹은 OAUTH2.0)를 입력
- 인증 서비스는 회원 DB와 비교하여 ID,PW 가 올바르면 인증 토큰을 발급하며 Serivce 1으로 돌려보냄
- Service 1 은 발급된 토큰을 확인하고, 올바른 토큰이라면 사용자의 로그인 처리를 진행
- 사용자는 Serivce 2에 접속
- Serivce 2 (Service 1의 하위 서비스) 는 이 사용자의 세션이 아직 유효한지 확인하고, 유효하다면 Service 2 용도의 토큰을 발급
- Serivce 1 은 발급된 토큰을 확인하고, 올바른 토큰이라면 사용자의 로그인 처리를 진행
인증 토큰의 내용 및 유효성 검사 방법
- 인증 서버(idP)와 각 Service 서버들은 사전에 비밀키(Primary Key)를 공유한다.
- ID, PW로 정상적인 인증이 확인되면, 인증 서버는 토큰에 이메일, 이름, 유효 시간 등을 입력하여 발급한다.
- 토큰을 Base64 Encoding 한다. 이는 암호화가 아닌 인코딩이기 때문에 내용은 누구나 확인 가능하다.
(내용을 숨기기 위한 암호화가 아니라, 전송을 용이하게 하기 위한 인코딩) - HTTPS 보안 채널로 토큰 확인을 요청한다. 이 과정에서 토큰이 유실되더라도 인증 서버와 Service 서버들이 공유하고 있는 비밀키가 없는 해커는 토큰의 내용을 변조할 수 없다.
(서비스 서버는 받은 토큰이 인증 서버에서 발급된 것인지, 변조되지 않았는지를 비밀키를 이용하여 확인) - Service 서버는 비밀키로 토큰 변조 여부를 확인하고, 이메일 등의 사용자 정보를 확인 후, 인증 처리를 진행한다.
Refresh Token
인증된 사용자가 세션이 만료됐을 때, 사용자를 다시 인증하지 않고 액세스 토큰을 갱신할 수 있게 해주는 토큰
대부분의 인증 시스템에서는 보안을 위해 액세스 토큰의 유효 시간을 짧게 설정합니다.
이 경우, 액세스 토큰이 만료되면 사용자는 다시 로그인해야 하는 번거로움이 발생할 수 있는데, 리프레쉬 토큰을 사용하면 이러한 불편을 줄일 수 있습니다.
리프레쉬 토큰의 작동 방식
- 인증 과정: 사용자가 최초로 로그인할 때, 인증 서버는 액세스 토큰과 함께 리프레쉬 토큰을 발급합니다.
- 액세스 토큰 사용: 사용자는 발급받은 액세스 토큰을 사용하여 리소스에 접근합니다.
- 액세스 토큰 만료: 액세스 토큰의 유효 시간이 지나면, 더 이상 리소스에 접근할 수 없게 됩니다.
- 리프레쉬 토큰으로 액세스 토큰 갱신: 사용자는 리프레쉬 토큰을 인증 서버에 전송하여 새로운 액세스 토큰을 요청합니다.
- 새 액세스 토큰 발급: 인증 서버는 리프레쉬 토큰을 검증한 후, 새로운 액세스 토큰을 발급합니다.
[개념] SSO(Single Sign-On) 이란?
SSO(Single Sign-On)의 개념 SSO(Single Sign-On; 통합인증)는 말 그대로, 한 번의 인증 과정(로그인)으로 여러 컴퓨터 상의 자원을 이용 가능하게 하는 인증 기능이다. 과거에는 위 그림처럼 각 어플리케이
co-no.tistory.com
'공부' 카테고리의 다른 글
| 우분투 ImageMagick 이용해서 이미지 사이즈 일괄 변경하기 (0) | 2024.03.25 |
|---|---|
| Windows에서 IE11 실행시키는 방법 (0) | 2024.03.20 |
| ES5 문법 호환을 위한 Webpack, Babel 설치와 사용 (0) | 2024.03.12 |
| 자바 웹 개발 워크북 (1-1~2) - 자바 웹 개발 환경 만들기 (0) | 2024.02.22 |
| [JAVA] JWT (JSON Web Token) - Cookie, Session, Token (1) (0) | 2023.11.09 |
