-
OAuth2.0 이란 ?카테고리 없음 2024. 6. 13. 16:30
이 글은 본격적으로 프로젝트하기 전에 OAuth2.0의 이론을 공부하고 작성한 글이다
인증과 인가
왜 나왔을까?
- A라는 서비스가 있다
- 유저는 A 서비스를 이용하기위해 로그인을 하려고한다 그래서 구글 Id와 패스워드를 A 라는 서비스에 넘겼다
- A 서비스는 구글에 로그인을 시도하였다
- 로그인 성공한 뒤 사용자 정보를 받고 유저에 서비스를 제공 했다
이런식으로 진행이 되는데
하지만! 여기에는 큰 문제가 있다
1. 유저 입장에서는 A 서비스를 신뢰 할 수 없다
- 유저가 A 서비스에 구글 Id와 패스워드를 줌으로써 A 서비스가 유저의 구글 정보를 이용해서 어떤 정보를 가져오고 악용할지 모르기 때문이다
2. A서비스 입장에서는 큰 부담을 가지게 된다
- A 서비스에서 유저의 구글 Id와 패스워드를 직접 관리하는건 엄청난 부담을 가지게 된다
- 관리하다가 갑자기 노출이 된다면 서비스를 중단하고 접어야한다
3. 구글 입장
- 구글 자신들의 보안 수준을 높여서 개발을 했는데 A서비스로 인하여 유저들의 정보가 외부에 노출 된다면 이런 보안 조치한 것들이 다 소용이 없어진다
즉, 이러한 문제들은 A서비스가 유저의 Id와 패스워드를 직접 받고 관리해서 생기는 문제이다
그러면 왜? A서비스는 유저의 구글 Id와 패스워드를 받았을까?
-> 왜냐하면 A 서비스가 필요로 하는 유저의 정보를 구글로부터 가져오기 위함이다
즉, 인가 과정 때문이다
하지만 인가를 위해서는 인증과정이 선행되어야 한다
이러한 문제을 어떻게 해결할까?
그냥 예시 유저가 직접 인증을 수행하고 A 서비스는 권한만 받으면 된다
이렇게 해서 OAuth가 등장하게 된 배경이다
OAuth 흐름
우선 요약을 하자면
- 인증은 유저가 직접
- 권한은 서비스에게
1. 로그인 1. 유저는 구글에 직접 Id 와 패스워드를 입력하여 인증 과정을 수행한다
- 이때 A서비스는 이 인증 과정에서 어떠한 행동을 하지 않고 포함되지 않는다
- 따라서 중간에 탈취당하거나 그러한 염려가 없어진다
2. 권한 부여 2. 인증 과정이 끝나고 인증이 유효하다고 확인이 되면 구글은 A서비스에서 필요로 하는 해당 사용자의 정보 접근을 A서비스에 부여를 한다
3. 정보에 접근 3. A서비스는 이 부여받은 권한으로 A서비스에서 필요로 하는 사용자의 정보에 접근을 한다
- 이때 유저는 권한을 부여하는 과정에서 어떠한 관여하지 않는다
- 이러한 이유는 권한이 탈취될 범위를 최대한 좁혀서 보안적인 이점을 가지기를 위함이다
OAuth Role
앞서 말한 유저, A 서비스, 구글을 OAuth 에서 부르는 명칭이 있다
OAuth Role 1. 유저 -> Resource Owner
- Resource Owner : 인증을 수행하는 주체
2. A서비스 -> Client 또는 Third-party Application
- Client 또는 Third-party Application : 권한을 위임받는 주체
3. 구글 -> Authorization Server, Resource Server
- Authorization Server : 인증을 검증하고 권한을 부여하는 주체
- Resource Server : 인가을 수행하고 리소스를 제공하는 주체
권한 부여 방식
권한 부여 방식에는 4가지의 방식이 있는다
1. Authorization Code Grant (권한 부여 승인 코드 방식)
2. Implicit Grant (암묵적 승인 방식)
3. Resource Owner Password Credentials Grant (자원 소유자 자격증명 승인 방식)
4. Client Credentials Grant (클라이언트 자격증명 승인 방식)
이 글에서는 1. Authorization Code Grant 방식만을 설명 하도록 하겠다
이유는 우리가 원하는 서비스의 대부분이 이 방식을 지원 해준다
그래서 이것만 알아도 OAuth 서비스를 이용하는데에 큰 불편함 점은 없을 것이다Authorization Code Grant │ 권한 부여 승인 코드 방식
- 권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식으로 많이 쓰이고 기본이 되는 방식이다
- 간편 로그인 기능에서 사용되는 방식
- 클라이언트가 사용자를 대신하여 특정 자원에 접근을 요청할 때 사용되는 방식
- 보통 타사의 클라이언트에게 보호된 자원을 제공하기 위한 인증에 사용됨
- Refresh Token의 사용이 가능한 방식이다
과정
1. Resource Owner가 먼저 Client에 OAuth 요청을 한다
2. 서비스에서는 로그인 페이지 URL을 제공한다
3. User-Agent에서는 Authorization 서버에서 URI를 요청해서 로그인 페이지 접근한다
4. URI의 쿼리 파라미터를 보면 여러가지 쿼리 파라미터가 있다
- response_type은 OAuth Flow의 Authorization 코드를 나타내는 것
- client_id 는 식별자를 의미
- redirect_uri 는 권한을 다시 반환 받는 엔드포인트가 됨
- scope 는 허용한 권한들 이런 것들이 들어가게 된다
위와 같이 OAuth 세팅하면서 설정한 것들이 전부 다 uri 쿼리 파라미터에 들어가게 된다
5. 로그인 화면에서 유저가 인증과정을 진행한다
- 클라이언트는 오로지 로그인 페이지에 URL만 제공해주고
- 전부 다 Resource Owner와 Authorization 서버만 참여하고 있다
6. 이러한 인증이 유효하다고 판단되면 Authorization Server에서는 access token 즉, 권한을 받을 수 있는 authorization 코드를 반환해 준다
7. client에서는 이 authorization 코드를 가지고 access token이라는 실제로 사용하는 권한을 발급 요청을 한다
이때! 여러가지 또 옵션들이 들어가야 한다
- code같은 경우에는 반환받은 authorization 코드
- client_id 는 식별자
- client_secret은 OAuth 세팅에서 이 access token을 요청하는 주체가 서비스에 등록된 클라이언트인지 확인하는 용도
- redirect_uri 는 access token을 반환 받을 엔드포인트를 의미
- grant_type 은 위에 네가지 방식 중 하나인 authorization code가 들어가게 된다
8. 인증이 마치면 authorization 서버에서 accesstoken과 refreshToken을 발급해준다
이렇게 동작 하는 것이다
여기에서 중요한 점은
인증과정 권한을 다 부여 받은후
9. 권한을 다 부여 받으면 Resource Owner가 서비스를 요청하면 Client는 Resource Server에 AccessToken과 리소스를 요청
10. Resource Server는 AccessToken 검증한 후에 리소스를 반환해준다
11. 반환받은 리소스를 가공해서 서비스를 Resource Owner에 제공해준다
그 외의 부분
OAuth2.0 open api 을 제공하는 회사들 목록으로는
기업 OAuth 2.0 구글 O 깃허브 O 네이버 O 카카오 O 이렇게 있고 서비스를 만들때 적절하게 사용하면 될 것 같다
참고