OAuth 2.0
– 인증 중개하는 메커니즘.
– 보안 리소스에 액세스하기 위해 클라이언트에 권한을 제공하는 프로세스를 단순화하는 프로토콜.
– 이미 사용자 정보를 가지고있는 웹 서비스 (네이버, 카카오 등)에서 사용자 인증을 대신하여 액세스 권한에 대한 토큰를 발행한 후 이를 이용하여 내 서버에서 인증이 가능해진다.
– 자주 사용하는 중요한 서비스(네이버, 카카오)의 ID와 password만 기억하고, 그 서비스를 통해 외부 서비스에 소셜 로그인을 할 수 있다.
인기글
– 보안상의 이점이 있다.
검증되지 않은 앱에서 OAuth를 사용하여 로그인하는 경우 사용자의 기밀 정보가 앱에 직접 노출되지 않고 사용자에게 인증 권한을 미리 얻어야 하기 때문에 보다 안전하게 사용 수 있습니다.
OAuth의 주체
1. Resource Owner
-OAuth 인증으로 소셜 로그인을 원하는 사용자.
-resource는 사용자 이름, 전화 번호 등의 정보를 의미합니다.
정보의 소유자가 바로 사용자이기 때문에, resource owner라고 한다.
2. Resource Server & Authorization Server
– 사용자가 이미 사용하고 있는 서비스(네이버, 카카오 등)의 서버 중 사용자의 정보를 저장하고 있는 서버를 특정하여 Resource Server라고 부른다.
– 이미 사용중인 서비스의 서버 중 인증을 담당하는 서버를 식별하고 인증 서버라고합니다.
3. Application
– 사용자가 소셜 로그인을 활용하여 이용하고 싶은 (가입하고 싶은) 새로운 서비스.
– 환경에 따라 조금씩 다르게 부른다.
– 경우에 따라서는 Application을 client와 server로 세분화하여 지명할 수도 있다.
OAuth 인증 체계의 유형과 흐름
– Grant Type: Authorization Server에서 Access Token을 받는 방법
1. Implicit Grant Type
1. 사용자가 응용 프로그램에 연결합니다.
2. application에서 authorization server로 인증 요청을합니다.
3. 유효한 인증 요청인지 확인하고 액세스 토큰을 발행합니다.
4. authorization server에서 application으로 액세스 토큰을 전달합니다.
5. application은 발행 된 액세스 토큰을 포함하고 리소스 서버에 사용자 정보를 요청합니다.
6. 액세스 토큰이 유효한지 확인하십시오.
7. 유효한 토큰이면 응용 프로그램에서 요청한 사용자의 정보를 전달합니다.
8. 새로운 서비스를 시작할 수 있습니다!
# 소셜 로그인에서는 Implicit Grant Type이 제대로 작동하지 않습니다.
기존 서비스에 로그인하는 것만으로는 새로운 서비스에 직접 액세스 토큰을 내주기 때문에 보안이 조금 떨어지기 때문이다.
따라서 일반적으로 여기에 인증 단계를 한 단계 추가한 인증 방식 아래에 있는 Authoriztion Code Grant Type을 주로 사용한다.
2. Authoriztion Code Grant Type
1. 사용자가 응용 프로그램에 연결합니다.
2. application에서 authorization server로 인증 요청을 보냅니다.
3. authorization server는 유효한 인증 요청임을 확인한 후 authorization code를 발행한다.
4. authorization server에서 application으로 authorization code를 전달합니다.
5. application이 authorization code에서 발행된 authorization code를 전달합니다.
6. authorization server가 유효한 authorization code인지 확인한 후 액세스 토큰을 발행합니다.
7. 응용 프로그램에 액세스 토큰을 전달합니다.
8. application은 발행 된 액세스 토큰을 포함하고 리소스 서버에 사용자 정보를 요청합니다.
9. resource server는 application에서 전달된 액세스 토큰이 유효한 토큰인지 확인합니다.
10. 유효한 토큰이면 응용 프로그램이 요청한 사용자의 정보를 전달합니다.
# Implicit Grant Type과 비교하면 authorization code를 사용한 인증 단계가 추가되어 비교적 안전합니다.
또한 원하는 경우 아래 그림과 같이 토큰을 application의 client에 공개하지 않고 server에서만 관리할 수도 있으므로 소셜 로그인을 구현하는 방식의 선택사항이 늘어나게 된다.
3. Refresh Token Grant Type
– 액세스 토큰이 만료되었을 때를 대비하여 액세스 토큰을 발행할 때 리프레시 토큰을 함께 발행해 주는 경우도 있다.
– 새로 고침 토큰을 사용하여 액세스 토큰을 받는 인증 방법.
-authorization server에 새로 고침 토큰을 보내면 authorization server는 새로 고침 토큰을 확인한 다음 액세스 토큰을 다시 발행합니다.
애플리케이션은 재발행된 액세스 토큰을 사용하여 자원 서버로부터 사용자 정보를 수신합니다.
OAuth의 장점
1. 쉽고 안전하게 새로운 서비스를 이용할 수 있다.
– 유저는 ID, 패스워드등의 정보를 매일 입력하지 않아도 클릭 몇 번으로 간단하게 등록할 수 있어 편리하다.
– 정보를 해당 서비스에 직접 공개하는 것이 아니기 때문에 직접 가입하는 것보다 안전하다.
-application의 입장에서도 회원의 정보를 직접 가지고 있기 때문에 발생할 가능성이 있는 회원 정보 유출의 위험성으로부터 부담을 경감할 수 있다.
2. 권한 영역을 설정할 수 있습니다.
-OAuth 인증을 허가해도, 새로운 서비스가 사용중이었던 서비스의 모든 정보에 액세스 할 수 있는 것은 아니다.
사용자는 필요한 정보에만 액세스할 수 있으며 더 안전합니다.
-OAuth 설정 페이지에서 애플리케이션에 필요한 정보를 선택할 수 있습니다.
사용자는 이중 원하는 정보만을 선택적으로 제공할 수 있다.