깃허브 로그인, 카카오 로그인, 구글 로그인처럼 OAuth의 사용을 통한 프로젝트 경험이 존재했다.
난 백엔드 개발자와만 소통해보고 사실 이번 프로젝트에 프론트와의 첫 프로젝트를 시작하게 되었다.이번 프로젝트에서는 구글 로그인을 적용하게 되었는데.. 프론트 개발자분의 구글 로그인에 대한 질문에 내가 답을 못한다는 사실에 내 지식의 수준을 알게 되었다. 정말 얕게 알고 있었다.
로그인 요청 → 구글 서버에서 토큰 줌 → 그걸로 로그인 검증
이 정도만 알고 있었다. 하지만 이게 제대로 된것인지, 이러한 방법만 있는 것인지 등 모르는게 너무 많아서 학습할 필요가 있다는 생각이 들었다. 오늘 끝장내보자!
OAuth 적용 후 전체적인 흐름
구글 캘린더를 사용하고, 체리 캘린더라는 웹앱을 만든다고 가정
- 유저는 구글에 아이디와 패스워드 입력을 통한 인증 과정 수행
- 이때 체리 캘린더는 이 인증 과정 어디에도 포함X
- 만약 이 인증이 유효하다고 판단이 되면
- 구글이 유저의 구글 캘린더에 접근할 수 있는 권한을 부여
- 체리 캘린더는 이 부여받은 권한으로 유저의 구글 캘린더에 접근
- 이때 유저는 이 권한을 부여받는 과정 어디에서도 관여X
- 권한이 탈취될 수 있는 범위를 최대한 좁혀서 보안적인 이점을 얻기 위함
- 이때 유저는 이 권한을 부여받는 과정 어디에서도 관여X
OAuth 정리
인증은 유저가 직접, 권한은 서비스에게 !
OAuth 규칙
- 유저(Resource Owner) : 인증을 수행하는 주체
- 체리 캘린더(Client Third-party Application): 권한을 위임받는 주체
- 구글(Authorization Server / Resource Server)
- Authorization Server: 인증을 검증하고 권한을 부여하는 주체
- Resource Server: 인가를 수행하고, 리소스를 제공하는 주체
OAuth 설정
GoogleCloud의 OAuth 설정을 참고하자. 보안 때문에 전체 캡쳐는 안했다.
설정에서 중요하게 봐야할 것
- 승인된 리디렉션 URI
- 권한을 다시 서비스(체리 캘린더)에게 전달해 줘야 하는데 이 서비스가 받는 URI
- 클라이언트 ID
- 나중에 서비스(체리 캘린더)의 식별자로 사용이 될 것
- 클라이언트 보안 비밀번호
- 권한을 요청하는 주체가 실제로 유저가 인증한 서비스(체리 캘린더)인지 확인하기 위한 수단
권한 부여 흐름
-
사용자(Resource Owner)가 먼저 OAuth 요청
-
서비스(체리 캘린더, Client)에서 로그인 페이지에 URI 제공
-
브라우저(User-Agent)에서는 이걸 구글(Authorization 서버)에서 URI를 요청해서 로그인 페이지에 접근
-
중요하게 봐야할 것: URI
https://accounts.google.com/v3/signin/identifier? response_type = code &client_id=~~~ &redirect_uri=~~~ &scope=~~~ ... -
위 코드는 예시. 중요하게 봐야할 것
- response_type
- 서비스가 사용하는 OAuth Flow의 Authorization 코드
- client_id
- (OAuth 설정에서 나온) 식별자
- redirect_uri
- 권한을 다시 반환 받는 엔드 포인트
- scope
- 허용한 권한들
- response_type
-
-
인증이 유효하다고 판단된다면 구글(Authorization Server)에서는 access token(권한을 받을 수 있는 authorization 코드)을 반환
-
서비스(체리 캘린더, Client)에서는 이 authorization 코드를 가지고 access token이라는 실제로 사용하는 권한 발급 요청
- 이 때, 여러가지 옵션들이 들어가야한다.
- 예시
POST /token HTTP/1.1 Host: oauth2.googleapis.com Content_Type: application/x-www-form-urlencoded code=~~~& client_id=~~~~& client_secret=~~~& redirect+uri=~~~& grant_type=authorization_code
- code
- 3번 과정에서 반환 받은 authorization 코드
- client_id
- 식별자
- client_secret
- OAuth 설정에서 중요하게 봐야할 것 2번
- 액세스 토큰을 요청하는 주체가 서비스에 등록된 클라이언트인지 확인하기 위한 목적
- redirect_uri
- authorization 코드를 반환 받을 access token을 반환 받을 엔드 포인트
- grant_type
- authorization code가 들어가면 됨
- 인증이 끝나면 구글(Authorization Server)에서는 access token과 refresh token을 반환
- 주의
- 서비스(체리 캘린더, Client)와 구글(Authorization Server)만 권한을 부여하는 과정에 참여 → 권한 부여하는 범위를 줄이며 보안 강화
- HTTPS로 암호화 필수(권장)
- 서비스(체리 캘린더, Client)와 구글(Authorization Server)만 권한을 부여하는 과정에 참여 → 권한 부여하는 범위를 줄이며 보안 강화
- 주의
- 권한을 다 부여받으면 사용자(Resource Owner)가 서비스를 요청하면 Client(체리 캘린더)는 이 access token과 함께 구글(Authorization Server)에 리소스 요청
- 구글(Authorization Server)은 이 access token을 검증한 후에 Client(체리 캘린더)에게 리소스 반환
- Client(체리 캘린더)는 이를 가공해서 사용자(Resource Owner)에게 서비스 제공
소셜 로그인: Open ID Connect
- OAuth는 인가를 위한 기술
- 소셜 로그인은 인증임
* 이를 지원하기 위해 OAuth 2.0에서 추가적으로 서비스가 들어가는 Open ID Connect라는 기술 사용!- Open ID Connect
- OAuth 인증 과정과 전부 똑같고 구글(Authorization Server)에게 서비스(체리 캘린더, Client)가 권한을 부여받는 과정에서 access token과 함께 ID token 발급 요청을 받음
- 이 ID token을 구글(Authorization Server)는 반환 해줌
- ID token은 JWT로 이뤄져있기 때문에 디코딩을 하면 사용자의 식별자를 얻을 수 있음 → 이를 통해 사용자 생성(회원가입)이나 JWT 생성 후 반환 가능
- 나머지는 다 동일함!
- Open ID Connect
