1. OAuth란?
: Open Authorization, Open Authentication
oAuth는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로써 사용되는, 접근 위임을 위한 개방형 표준이다.
사전적 정의로는 이렇지만 이러면 쉽게 이해하기 어렵다.
생활코딩 강의를 참고해 서술하면
새롭게 이용하고자 하는 사이트에서 사용자의 구글, 페이스북 아이디와 비밀번호를 요청하면 사용자 입장에서는 잘 모르는 사이트에게 자신의 구글, 페이스북 아이디와 비밀번호를 알려줘야 하는 부담을 가진다.
사용자 입장에서는 잘 모르는 사이트에 이것을 알려주는 것이 불안하고 사이트 입장에서는 이런 중요한 정보를 관리하는 데 부담을 느낀다.
이러한 문제를 해결해주는 것이 oAuth이다. 사용자가 사용하려는 새로운 웹사이트와 구글, 페이스북과 같은 사이트 사이에서 서비스를 이용할 수 있도록 도와준다.
2. OAuth 작동 방법
아이디와 비밀번호가 아닌 Access Token을 발급해줘서 Access Token으로 사용자를 식별할 수 있게 한다.
Access Token 이용함으로써 구글과 페이스북의 아이디와 비밀번호를 잘 모르는 사이트에 넘기지 않아도 되고 새로운 사이트가 자신의 구글과 페이스북의 모든 기능이 아닌 꼭 필요한 기능만 접근하도록 할 수 있다.
3. OAuth 용어
Resource server : 제어하고자 하는 자원을 갖고 있다.
(구글,페이스북과 같은 사이트)
(Resource server와 Authorization server를 보통 구분하지만 이 글에서는 하나로 여긴다.)
Resource owner(=user) : 자원의 소유자이다.
Client : Resource server에 접속해서 자원을 가져간다.
4. 사용 방법
1. 등록 (Client가 Resource Server에게 등록)
서비스마다 등록 방법은 다르지만 등록 후에는 공통으로 3가지를 공유하게 된다.
- Client ID : 자신의 웹 사이트의 클라이언트를 식별할 수 있는 ID
- Client Secret : 자신이 구현할 웹 사이트의 클라이언트를 구별할 수 있는 키
(절대 외부 노출 X) - Authorized redirect URL : https://client/callback
(Resource server가 권한을 부여하는 과정에서 Authorized code라는 것을 이 주소로 전달함)
2. Resource Owner의 승인
사용자가 redirect_uri가 연결된 버튼을 눌러 Resource server로 접속하게 되면
2-1) Resource owner의 로그인 여부에 따라 로그인이 되어 있지 않으면 로그인을 요청한다. 로그인에 성공하면
2-2) Resource server가 client id를 확인하고 redirect URL이 같은지 확인하고 둘 다 같다면 접속한 사이트에게 요청한 scope를 허락할 것인지 확인 페이지를 띄운다.
2-3) Resource onwer가 이를 수락하면 Resource server는 user id와 scope를 별도로 저장한다.
3.Resrouce Server의 승인
3-1) Resource Server가 Resource owner에게 임시비밀번호(authorization code)를 전송한다. (Location: https://client/callback?code=3-> 리다이렉션 문장
3-2) 이 문장을 통해 Resource owner도 모르게 위의 문장으로 이동하게 된다. code=3이란 문장을 통해 Client는 authorization code가 3임을 알게 된다.
Client는 전달받은 임시비밀번호를 이용해 Resource Server에 직접 접속한다.
client id,redirect uri, client secret도 추가로 전송해서 식별한다.
3-3) 전달받은 authorization code와 나머지 추가 정보를 Resource server에게 전송하고 Resource server는 자신이 갖고 있는 정보와 client가 전송한 정보가 일치하는지 확인한다.
모두 일치한다면 Resource server의 승인을 받은 것이고 access Token을 발급받을 준비가 끝난 것이다.
⭐️ 4. Access Token 발급 받기 ⭐️
임시 비밀번호인 authorization code를 통해 인증을 받았으니 authorization code를 지워준다.
Resource server가 Client에게 Access Token을 발급해준다.
client는 내부적으로 Access Token을 저장한다. 이제 Access Token을 이용해 user id와 scope를 알아낼 수 있다.
이제 발급받은 Access Token을 이용해 API를 통해 Resource server의 기능을 사용할 수 있다.
5. OAuth 2.0 인증 종류
- Authorization Code Grant: 권한 코드 승인 방식
- Implicit Grant: 암시적 승인 방식
- Password Credentials Grant: 비밀번호 자격 증명 방식
- Client Credentials Grant: 클라이언트 자격 증명 방식
- Authorization Code Grant
일반적으로 서버 사이드에서 인증을 처리할 때 사용하는 방식으로 Resource Owner로부터 리소스 사용에 대한 허락을 의미하는 Authorization code를 이용하여 Access Token을 요청하는 방식이다. Access Token이 바로 클라이언트에게 전달되지 않기 때문에 다른 방식보다 보안에 좋다. - Implicit Grant
권한 코드 없이 바로 토큰을 발급해주는 방식이다. Read only 서비스에서만 사용하는 것이 좋다. - Password Credentials Grant
Client에 서비스 제공자(구글,페이스북 등)의 아이디와 비밀번호를 저장해두고 사용하는 방식이다. Client와 서비스 제공자의 관계가 아주 긴밀할 때만 사용하는 것이 좋다. - Client Credentials Grant
Client와 Resource owner가 같을 때 사용하는 인증 방식이다. lient와 Resource Owner가 같기 때문에 추가적인 인증이 필요하지 않고 Authorization Server로부터 바로 토큰을 받을 수 있다.
Reference
https://libertegrace.tistory.com/entry/40-Authentication-OAuth-20?category=869766
