Oauth2.0
Oauth2.0 기술은 유저가 사용하려는 서비스에서 이미 유저가 가입되어있는 다른 서비스에게 유저인증과 유저리소스를 액세스 토큰을 사용하여 받는 기술.
Oauth2.0의 구성요소
Resource Owner : 리소스의 주인, 보통 사용자.
Client : 유저가 사용하려는 서비스 (여러 문서에 써드파티 서비스를 가르킨다.)
Authorization Server : 인증 서버 (유저가 이미 가입되어있는 서비스의)
Resource Server : 리소스 서버 (유저가 이미 가입되어있는 서비스의) 사용자들의 여러 정보, 기능들이 들어가 있다.구조 (대표방식)
먼저, RFC6749에 근거한 다이어그램표를 보면, 이미 등록이 이뤄진 상태에서 다음과 같은 순서를 진행한다.
(클라이언트는 이미 인증서버에 인증을 한 이후를 나타낸다 그래서 아래와같은 등록과정을 추가했다.)
사전단계 ) Client를 이미 유저가 가입되어있는 서비스(네이버,구글,카카오톡,페이스북,애플,트위터..)에 등록. (각 서비스마다 등록하는 방식이 상이하다.)
등록과정에서 공통적으로 설정하는부분 redirect URI, 받아야하는 정보 Client_id , Client_secret, 해당서비스의 코드설정
-
Client (우리의 서비스)에서 자격증명 요청을 보낸다.
[로그인 버튼을 눌러 Resourcer Owner 에게 로그인 요청을 함, 이때 작은창으로 보통 authorization server와 연결된 로그인화면이 나옴] -
Resourcer Owner는 자격 증명을 완료한 요청을 클라이언트에게 보낸다.
[로그인 완료 이후 클라이언트한테 요청한다고한다, 내가 느낀점은 작은화면에서 authorization server와 Owner가 즉각적으로 소통하는 것으로 보임 보통 로그인화면에 URI안에 Client가 Authorization Server에게 보낼 정보가 담겨져있다.] -
Client에서 자격증명 완료 되었다는 정보와함께 client정보를 Authorization Server로 보낸다.
-
Authorization Server에서 자격증명 완료 확인을 보고 Resource Server에서 자료를 받을 수 있는 Access Token을 Client한테 발급한다.
-
Client에서 Access Token을 갖고 Resource Server에 접근한다.
Resourcer Server는 Access Token을 확인하고 Client에게 Protected Resource를 전달한다.
다음과 같이 Oauth 2.0에 기본 프로토콜 플로우가 진행이 된다고 설명된다. (카카오v1버전일때 위와같은 플로우로 진행되었었다.)
액세스토큰을 받는 방식 4가지
Authorization Code Grant (권한부여 승인 코드)
Implicit Grant (암묵적 승인)
Resource Owner Password Credentials Grant (리소스 오너 자격증명)
Client Credentials Grant (클라이언트 자격증명) 자세한 예시는 RFC문서 또는 여러 좋으신 개발자분들의 기록일지를 보면 자세한구조와 설명이 서술되어있습니다.
https://datatracker.ietf.org/doc/html/rfc6749#section-4
https://chipmaker.tistory.com/entry/OAuth20-%EC%A0%95%EB%A6%AC
요즘은 대부분의 서비스에서 보안상의 이유로 Authorization Code Grant (권한부여 승인 코드) 방식을 취한다고 생각한다.
Authorization Code(인가코드)를 사용할때 보안성이 더 뛰어난 이유
- Access Token을 이전에 방식과달리 안전하게 통신하여 받을 수 있습니다.
- Resource Owner의 ID와 PW가 Client에게 직접적으로 노출되지않으며 , Client는 Authorization Code(인가코드)만 받습니다.
- Authorization Code(인가코드)의 수명이 짧아, 중간에 탈취 당하더라도 오용할 수 있는 기회를 막을 수 있게됩니다.
- Authorzation Server와 권한 부여를 위해 상호작용하는 단계가 늘어남에따라 보안성이 더올라갑니다.
- 클라이언트 프론트가아닌 백엔드에서 통신하게되어 Resource Owner에게 직접적으로 Access Token을 주지 않아도 권한 부여를 받을 수 있어 더욱 안전합니다.
구현에서의 모호함?
구현에있어서는 자유도가 높아 백엔드와 프론트의 확실한 소통이 필요하다고 생각합니다.
RFC문서나 여러 자료들을보면 구현하려는 우리의 서비스를 Client라고 명명하기에 프론트와 백엔드를 구분지어 생각하여 구현을 생각해야합니다.
다음과 같이 프로토콜 플로우를 수정할 수 있습니다.
다음과 같이 로그인을 진행할 수 있지않을까 생각된다. 인가 코드를 받는 형태로 추가된다면 자격증명 완료 후 액세스토큰이아닌 인가코드를 받는 과정을 추가하여
액세스토큰을 받는 방식으로 진행하면 되지 않을까 예상됩니다.
추후 카카오톡 또는 구글로그인을 이용한 Oauth 2.0 방식을 구현 하도록하겠습니다.(JAVA 공부를진행해서 풀스택을 향해)
참고 사이트 및 자료
https://opentutorials.org/course/3405 (생활코딩)
https://datatracker.ietf.org/doc/html/rfc6749 (RFC문서)
https://chipmaker.tistory.com/entry/OAuth20-RFC6749-%EC%A0%95%EB%A6%AC-2
https://hudi.blog/oauth-2.0/
