OAuth 2.0이란?
OAuth2.0에는 3명의 참가자가 있음
User는 (나의 서비스) 사용자
mine은 나의 서비스
Their은 나의 서비스가 연동하려고하는 그들의 서비스
ex)
사용자가 나의 서비스(mine)에 접속해서 글을 썼거나 봤다고 가정
-> 이때 나의 서비스(mine)가 사용자(User)를 대신해서 구글과 같은(Their) 서비스의 캘린더에 날짜를 기록한다거나, 페이스북에 봤던 글을 공유한다고 가정해보자
그럴러면 mine이 Their에 접근할 수 있도록 허가를 받아야 함
-> 가장 단순한 방법은 User가 Their에서 사용하는 Id/password를 사용자로부터 mine이 받아오는 것
-> mine이 아이디/패스워드를 통해 Their에 접속한다면 모든 기능들을 활용할 수 있기에 강력함
-> 하지만 상당히 보안상 문제가 되는 방법(사용자는 처음 보는 mine에게 아이디 비밀번호를 맡겨야 하는것!)
-> 이러한 문제를 해결하기 위한 것이 OAuth
OAuth 사용 전에는 mine이 user가 their에서 사용하는 id/pw를 가지고 있었음
OAuth 사용시
User의 요청에 의해 그들의 서비스(Their)가 Access Token(일종의 비밀번호)을 발급
-> 이 경우 Access Token은 아이디,비밀번호 그 자체가 아니라는 장점이 있고, 그들의 서비스가 가지고 있는 모든 기능이 아닌 그 중 나의 서비스(mine)가 필요로 하는 서비스만 부분적으로 허용하는 비밀번호
mine은 OAuth를 통해 their로 부터 토큰을 받고, 이를 통해 Their에서 데이터를 가져오거나,삭제하거나 등등 하고자했던 작업을 진행
요약하자면 OAuth를 통해 다른 서비스에 접근할 수 있는 권한을 획득하거나, 다른 서비스에게 권한을 부여할 수 있다
역할
아까 설명한 용어들을 OAuth에서 사용하는 용어로 바꿔보자!
User -> Resource Owner
Their -> Resource Server
Mine -> Client
공식 문서에 보면 Authorization Server가 존재하는데 Resource Server가 자원을 가지고 있는 서버라면 Authorization Server는 인증과 관련된 처리를 전담하는 서버
-> 합쳐서 보기도 함
OAuth 등록
Client가 resource server를 이용하기 위해서 사전에 승인을 받아내야함(등록 해야 함 : register)
Client Id는 우리가 만들고 있는 애플리케이션(클라이언트)을 식별하는 값
Secret은 Id에 대한 비밀번호(Id는 노출되도 되지만, 이는 노출되면 보안사고)
Authorized redirect URIs는 리소스 서버가 클라이언트 서버한테 권한을 부여하는 과정에서 클라이언트에게 Authorization Code를 전달해줌
-> 이때 코드를 이 주소로 전달해 달라고 알려주는 것
-> 리소스 서버는 위 주소가 아닌 다른 주소에서 요청을 한다면 무시할 것
Resource Server의 승인
client가 register를 마치게 되면
-> Resource Server는 client id 및 secret과 redirect URL이라는 3가지 핵심 요소를 알게 됨(클라이언트도 마찬가지)
예를들어 리소스 서버가 가지고 있는 기능이 각각 존재한다 가정(A,B,C,D)
-> 클라이언트가 B,C 기능만이 필요하다면 모든 기능에 대해 인증을 받는 것이 아닌, 필요한 기능에 대해서만 인증을 받음
Resource Owner가 Client에 접속한다고 가정
-> 사용 과정에서 클라이언트가 리소스 서버에 접근해야될 경우가 있다고 가정
-> 그러면 클라이언트는 밑과 같은 화면을 Resource Owner에게 보여줄 것
기능을 사용하기 위해선 인증을 거쳐야 한다는 의미(사용자 동의 필요)
이러한 버튼에 클릭 이벤트 발생 시 간단한 링크가 연결되게끔 하면 됨
https://resource.server/?client_id=1 & scope = B,C & redirect_uri = https://client/callback위와 같은 주소를 통해 Owner가 Resource Server로 접속 시 Server는 Owner의 로그인이 되어있는지 여부를 체크
-> 로그인이 안되어있으면 오너에게 로그인 화면을 보여줌
-> 로그인 완료 시 Resource Server는 링크 상에 client_id와 같은 아이디값이 있는지 확인 후, redirect uri까지 확인
-> 둘다 같다면 리소스 오너에게 scope에 해당하는 기능을 클라이언트에게 부여할것인지 확인하는 메세지 전달
이때 허용을 누르면, 허용했다는 정보를 리소스 서버가 수집하게 됨
리소스 오너의 유저아이디(1이라 가정)는, 스코프에 해당하는 메서드를 허용하기로 했다고 저장
Resource Server의 승인
앞선 작업을 통해 Resource Owner가 승인을 하였으니 이제는 Resource Server가 승인을 해주어야 함
-> 이때 바로 Access Token을 발급하지 않고 authorization code라고 하는 임시 코드를 발급
-> 이를 리소스 오너에게 전달
리소스 서버가 리소스 오너의 웹 브라우저에게 해당 주소로 이동하라는 명령(code는 Authorization code)
-> 오너가 저 주소를 타게되면 클라이언트에 접속하게 되고, 주소에 명시된 authorization code로 인해 client가 Authorization code값을 알게 됨
위와 같이 authorization code를 알게된 클라이언트는 위의 주소를 통해 리소스 서버에 직접 접속
-> 이때 두개의 비밀 정보를 결합하여 리소스 서버에게 전송하게 됨(authorization code + secret)
이때 리소스 서버는 클라이언트가 authorization code, redirect uri, client_id, client_secret이 완전히 일치하는지 확인
-> 일치한다면 Access Token을 발급해 줌
Access Token 발급
authorization code, redirect uri, client_id, client_secret이 완전히 일치하는지 확인후, 일치하다면 우선 리소스 서버는 자신이 가지고 있는 authorization code를 지움
-> 그 다음 accessToken을 발급
발급한 토큰을 클라이언트에게 내려줌
-> 이때 클라이언트는 AccessToken을 DB나 파일 같은 곳에 저장
이러한 Access Token은 클라이언트가 접근할시, 리소스 서버는 엑세스 토큰을 확인하고 이는 User_id 1번에 해당되는 사용자의 유효한 기능(b,c)에 대해 권한이 열려 있으니까, 이에 맞는 사용자의 정보를 주는 방식으로 동작
API 호출
Access token을 활용해서 리소스 서버를 호출해 하고자 하는 작업 실행
-> 이때 조작 방식을 알려주는 것이 API
ex) 구글 캘린더를 사용하고자 한다면 구글 캘린더 API 검색후 정보 참고
Access Token을 어떻게 활용해서 접근할지는 애플리케이션 따라 다름
https://developers.google.com/identity/protocols/oauth2/web-server?hl=ko#httprest_3
애플리케이션이 액세스 토큰을 얻은 후 API에 필요한 액세스 범위가 부여된 경우 토큰을 사용하여 특정 사용자 계정을 대신하여 Google API를 호출할 수 있습니다. 이렇게 하려면 access_token 쿼리 매개변수 또는 Authorization HTTP 헤더 Bearer 값을 포함하여 API에 대한 요청에 액세스 토큰을 포함합니다
예시
Refresh Token
일반적으로 Access Token은 수명이 제한되어 있음
-> 수명이 다 닮면 api 접속해도 데이터를 주지 않음
-> 다시 인증 받기 위해 사용자에게 인증을 요청하는 것은 복잡
-> 이러한 과정을 막기 위해 사용하는 것이 refresh Token
보통 Access Token을 인증 서버에서 발급 해 주면서 Refresh Token도 같이 발급해주는 경우가 많음
api를 호출할때는 Access Token을 제출하는 것을 통해 리소스 서버의 리소스를 가져옴(C)
-> 어느 순간 Invalid Token Error가 발생하면 이는 Access Token 수명이 끝났다는 것
-> 이때 클라이언트는 refresh token을 인증 서버에게 전달하면서, 엑세스 토큰을 다시 발급 받아옴
