1. 개념
- OAuth는 인증을 위한 오픈 스탠더드 프로토콜로, 사용자가 Facebook이나 트위터 같은 인터넷 서비스의 기능을 다른 애플리케이션(데스크톱, 웹, 모바일 등)에서도 사용할 수 있게 한 것이다.
- OAuth의 탄생 이전에도 다른 애플리케이션에 사용자의 아이디와 암호가 노출되지 않도록 하면서 API 접근 위임(API Access Delegation)이 가능한 여러 인증 방법이 있었다. Google과 Yahoo!, AOL, Amazon 등에서는 각각의 인증 방식을 제작하여 사용했다.
- OAuth는 인증을 인가하는 방식이다.(권한 부여)
2. OAuth와 로그인
사원증을 이용해 출입할 수 있는 회사를 생각해 보자. 그런데 외부 손님이 그 회사에 방문할 일이 있다. 회사 사원이 건물에 출입하는 것이 로그인이라면 OAuth는 방문증을 수령한 후 회사에 출입하는 것에 비유할 수 있다.
- 나방문씨(외부 손님)가 안내 데스크에서 업무적인 목적으로 김목적씨(회사 사원)를 만나러 왔다고 말한다.
- 안내 데스크에서는 김목적씨에게 나방문씨가 방문했다고 연락한다.
- 김목적씨가 안내 데스크로 찾아와 나방문씨의 신원을 확인해 준다.
- 김목적씨는 업무 목적과 인적 사항을 안내 데스크에서 기록한다.
- 안내 데스크에서 나방문 씨에게 방문증을 발급해 준다.
- 김목적씨와 나방문씨는 정해진 장소로 이동해 업무를 진행한다.
3. 역할
- Resource Owner(자원을 이용하는 사용자)
- Client(서비스홈페이지)
- Resource Server(필요한 자원을 가지고 있는 서버, 데이터서버)
- Authorization Server(권한을 관리하는 서버)
역할을 위 4가지로 구분할 수 있다.
4. OAuth의 accessToken의 역할
EX) 한 회원이 내 서비스에 글을 썼다고 가정한다. 내 서비스가 회원을 대신해서 Resource Server(구글)의 캘린더에 기록하거나 내용을 공유해준다.
위 예제가 가능하기 위해서는 구글에 접근할 수 있도록 사전에 허가를 받아야 한다.
가장 쉬운 방법은 Resource Server로부터 Resource Owner의 ID,PW를 전달 받아서 이용하는 것이다. 하지만 이러한 방법은 구글의 모든 기능을 다 사용할 수 있기 때문에 굉장히 위험한 행위이다.
OAuth를 이용하면 훨씬 안전하게 상호작용 할 수 있고, 회원의 요청에 의해 구글이 아이디와 비밀번호 대신 accessToken 이라고 하는 일종의 암호를 발급한다.
accessToken은 구글의 모든 기능이 아닌 그 중 나의 서비스가 필요한 필수기능만 부분적으로 허용하는 비밀번호이다. 나의 서비스는 OAuth를 통해 accessToken을 발급받고, accessToken으로 구글에 접근해서 데이터의 CRUD 작업을 할 수 있게 된다.
5. Authorization Code Grant의 절차
1) Client(Application Service)의 등록
Client가 Resource Server를 이용하기 위해서는 사전승인을 받아야 한다.
사전승인을 register라고 부르며, Resource Server마다 register 방법은 상이하다.
공통적으로 register에서 받는 데이터는 3가지 이다.
- Client ID : 식별자(노출 무방)
- Client Secret : Client ID에 대한 비밀번호 (노출 금지)
- Authorized redirect URIs : Authorization Code를 전달받을 주소
Resource Server로부터 권한을 부여 받는 과정에서 Authorization Code라는 값을 전달 받는다.
Authorized redirect URIs로 Authorization Code를 전달받게 되고 지정된 주소 이외의 다른 주소로 요청하게 되면 그 요청을 무시한다.
2) Resource Owner의 승인
ex)
2-1) Resource Owner는 나의 서비스에 접속한다.
2-2) 서비스 이용 과정에서 내 서비스가 페이스북 게시글을 조작하는 등의 Resource Server를 사용하는 작업을 해야 한다면 Resource Owner에게 소셜 로그인 버튼을 보여준다.
혹은 아래와 같은 메시지를 보여준다.
"귀하께서 하시는 일은 페이스북의 ~한 기능을 필요로 합니다. 그 기능을 사용하기 위해서는 인증을 거치셔야 합니다."
버튼을 클릭하거나 메세지를 읽고 다음 행위를 한다는 것은 Resource Owner의 동의를 거친다는 것을 의미한다. 버튼에는 링크를 걸어 주면 된다.
링크에는 Resource Server에 Client ID값, 사용할 기능(Resource Server가 정해놓은 형식), 인증코드를 전달받을 redirectURI를 쿼리 파라미터로 넘긴다.
2-3) Resource Owner가 버튼을 눌러서 Resource Server로 접속 한다.
2-4) Resource Server는 Resource Owner의 현재 로그인 여부를 파악한다.
→ 로그인이 되어 있지 않을 시, 로그인 화면을 띄운다.
2-5) Resource Owner는 로그인을 수행한다.
2-6) 로그인이 완료되면 Resource Server는 비교 검증을 수행한다.
서버주소 뒤에 파라미터로 넘어온 Client ID값과 동일한 Client ID값이 존재하는지 확인한다.
그리고 Resource Server가 갖고 있는 Client ID값에 해당하는 redirect URI 값이 접속을 시도하는 요청에 함께 넘어온 Redirect URI와 같은지 비교한다.
2-7) 비교 검증을 마치면 Resource Owner에게 scope에 해당하는 권한을 Client에게 부여할 것인지 확인 메세지를 전송한다.
"어떤 Client가 특정 항목들을 요청하고 있는데 허용할 것인가?"
2-8) 허용 버튼을 누르면 허용했다는 정보가 Resource Server로 전송된다.
2-9) Resource Server는 회원의 허용 정보를 수집한다.
3) Resource Server의 승인
Resource Server는 accessToken을 발급하기 전에 임시 암호인 Authorization Code를 발급한다.
(삼자간의 인증 절차를 위해서)
3-1) Resource Server은 Authorization Code를 회원에게 전송한다.
(전송할 때 Header 값에 Location을 주는데, 이는 리다이렉션 명령에 해당한다.)
즉, Resource Server가 회원의 웹브라우저에게 https://client/callback?code=3 이라는 주소로 이동하라고 명령한 것이다. ?code=3 부분이 Authorization Code에 해당한다.
3-2) Resource Owner의 웹브라우저는 주어진 주소로 이동하고, Client는 이 주소를 바탕으로 Authorization Code를 알게 된다.
3-3) 이제 Client는 Resource Owner을 통하지 않고 Resource Server에 직접 접속 한다.
지금까지 알아낸 정보와 client_secret을 함께 보낸다.
3-4) Resource Server는 Client가 넘긴 code와 Client ID, Client_Secret, Redirect URI 4가지가 모두 일치하는지 확인하고 다음 단계로 넘어간다.
4) Access Token 발급
4-1) Authorization Code를 통해 인증을 마쳤으므로 Resource Server는 code값을 지워야 한다.
그래야 다시 인증하지 않는다.
4-2) 그 후 Resource Server는 AccessToken을 발급하고 Client에게 응답해준다.
4-3) Client는 AccessToken을 내부적으로 서버에 저장한다.
앞으로 Client가 Resource Server에게 알맞는 AccessToken으로 접근하면 발급한 정보를 확인하고 유효한 기능에 대해서 접근을 허용한다.
도움이 되셨다면 하트 부탁드립니다♥
출처
https://opentutorials.org/course/3405
'보안' 카테고리의 다른 글
| [Windows Server] 익명 로그온 비활성화 ( ANONYMOUS LOGON) (0) | 2021.07.05 |
|---|---|
| [JWT] JSON Web Token 이란? (0) | 2021.05.01 |
| [Windows Server] 원격 접속 포트 변경하기 (0) | 2021.03.15 |
| Let's encrypt를 통한 무료 SSL 인증서 발급하기 (0) | 2021.03.02 |
댓글