일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 |
- linuxr계정설정
- heapq
- haproxy
- terraform backend
- terraform main commands
- Python
- terraform 설치
- 프로그래머스
- Docker
- SELinux비활성화
- Jenkins
- terraform 기본개념
- s3
- java
- session manager
- PrivateSubnet
- lsof
- endpoint
- JWT
- terraform variable
- terraform
- algorithm
- 인텔리제이
- 이진탐색
- Process monitoring
- Jenkinspipeline
- Mac
- binarysearch
- ec2
- Timezon설정
- Today
- Total
MONG 기술블로그
OAuth 2.0 이론 본문
OAuth란
OAuth란 특정 플랫폼(네이버/카카오)의 사용자를 인증할수 있는 accessToken을 플랫폼으로부터 발급받은 뒤, 개인적으로 구축한 서버에서 해당 accessToken을 이용하여 해당 플랫폼의 서비스에 대한 권한을 인가받는 기술이다.
나의 서비스에서 Naver와 연동된 기능을 사용하려고 할때 가장 편한 방법은 무엇일까 ?
가장 편한 방법은 사용자로부터 Naver 계정의 ID / PW를 유저로부터 제공받은 뒤 인증정보를 이용하여 서비스를 제공할 수 있다.
근데 해당 방법은 유저 / 네이버 의 입장에서 보았을때 플랫폼 사용자의 매우 중요한 인증정보를 제공하는 것 이기에 매우 바람직하지 않을 것이다.
OAuth를 사용한다면 이러한 민감한 부분을 해결할 수 있다.
간단한 예시를 들자면 다음과 같다.
나의 서비스는 네이버로부터 특정 사용자의 제한된 권한을 제공하는 accessToken을 제공받아 이를 통해 네이버에 인증을 허가받음으로써 네이버의 기능을 제공할 수 있다.
해당 accessToken은 일단 계정의 ID/PW 인증방식과 달리 비밀번호를 필요로 하지 않으며, accessToken은 사용할수있는 시간이 한정되어있기에 영원히 사용할 수 있는 수단이 아니기에 ID/PW 를 저장하여 인증하는 방식과는 비교할수없이 안전한 방법이다.
따라서 금번 블로깅을 통해 OAuth가 무엇인지에 대해 알아보고 추후 블로깅에 실제 구현함으로써 해당 기술지식을 구체화해보자.
오픈 API 신청
첫번째로 할 일은 사용하고자하는 플랫폼 ( 네이버 / 카카오 ) 에 오픈 API를 신청하는 일이다.
등록 방법은 각 플랫폼마다 조금씩 다르니 등록 후에 기본적으로 제공하는 정보만 명시 후 OAuth 방식에 대해 설명할 예정이다.
등록하고나면 다음과 같은 3가지 정보를 제공받을 수 있다.
- Client ID
- Client Secret
- (Authorized) Redirect URIs
이후 발급받은 정보를 가진 주체를 이미지로 표현하면 다음과 같다.

여기서 Resource Owner는 MyServer (내가 구축한 서비스를 제공하는 서버)에서 네이버/카카오 로그인 등을 이용하려고하는 사용자를 의미하며, Resource Server는 네이버/카카오 로그인에 대한 인증을 제공하는 서버를 의미한다.
이제 로그인 서비스를 예시로 Resource Server로부터 accessToken을 발급받는 방법을 순차적으로 설명할 예정이다.

첫번째로 User가 MyServer에 접속하여 네이버 로그인이 필요한 서비스를 이용하려고 할때 MyServer는 네이버 로그인 화면을 제공한다.
이때 네이버 로그인 화면은 좀전에 오픈 API를 신청할때 기입한 정보를 기반으로 client_id 및 redirect_url 정보를 담은 URL을 전달한다.

이때 제공된 URL로 접속하게되면 현재 네이버에 로그인 여부를 판단한 뒤 필요 시 ID/PW를 통해 인증을 요청한다.
인증이 완료된 뒤에는 Resource Server 에서 등록된 정보 ( client_id , redirect_url )의 유효성 여부를 판단한다.
유효성이 검증되면 User로부터 MyServer에 제공할 권한에 대한 동의여부를 물어본다.

User가 제공할 권한에 대해 동의하면 Resource Server에 해당 client_id에 대한 user_id를 새롭게 생성하여 저장한다.

이제 MyServer가 Resource Server로부터 해당 유저의 권한을 사용해도된다는 승인 절차 ( accessToken 발급 )를 진행하기위해
Resource Server에서 임시로 인증에 사용할 authorization_code(줄여서 code)를 생성한다.
그다음 User의 Response의 Header값에 Location:https://myserver/callback?code=3 과같은 값을 전달함으로써 자연스레 User가 MyServer로 임시로 발급받은 code값을 전달하게한다.

이제 MyServer는 User로부터 전달받은 code값을 포함하여 Resource Server로 redirect_url, client_id, client_secret 를 사용하여 Resource Server로 인증을 시도한다.
Resource Server는 자신이 가지고있는 authorization_code : 3 에 해당하는 client_id , client_secret , redirect_url의 정보 MyServer로부터 받은 정보와 일치하는지 확인한다. ( authorization_code : 3은 client_id : 1에 대해서 발급한 정보 )

마지막으로 이전 단계에서 모든 정보가 일치한다면 Resource Server는 AccessToken을 발급하여 MyServer에 전달함으로써 OAuth 인증에 필요한 AccessToken 발급이 완료된다.
acessToken 발급 이후에는 아래와 같이 발급받은 토큰 정보를 이용하여 API 호출이 가능하다.

이후 일반적으로 발급받은 accessToken을 통해 일반적으로 post header값에 토큰값을 넣어줌으로써 특정 유저의 권한으로 서비스 사용이 가능하다.