OAuth2 + JWT 구현에 이해가 어려운 부분이 있습니다.

Question

OAuth2 인증 방식을 통한 로그인을 구현하면서 JWT 을 적용하는데 이해가 가지 않는 부분이 있습니다.

공부를 하는 과정에서 
1. 직접 ID 와 Password 를 통한 로그인 방식
2. OAuth2 를 통한 로그인 방식
을 함께 구현해보려고 합니다.

1번 항목을 통해 로그인을 성공하면 JWT 를 통해 Access Token 과 Refresh Token 을 생성하고,
Access Token 으로 로그인한 유저의 정보를 사용하려고 합니다.
(예 : 쇼핑몰에서 장바구니를 눌렀을 때 로그인한 유저의 id값, DB의 장바구니 테이블에서 선택한 사람의 id값이 일치하는 경우)
token 을 사용해서 1번의 항목에 대한 부분은 구현이 완료되었습니다.

또한 2번 항목에서는 OAuth2로 로그인을 하면 Access Token 을 정상적으로 받아오는 부분까지 테스트를 통해 확인했고,
로그인 기능이 정상적으로 동작하는 부분까지도 확인했습니다.

헷갈리는 부분은 Access Token 에서 발생합니다.
예를 들어 구글 로그인이라고 할 때,
OAuth2 로그인 방식으로 발급받은 Access Token 은 클라이언트가 토큰이 만료되기 전까지는
로그인한 사용자의 정보를 가지고 있으며 이를 통해 리소스 서버에 필요한 서비스를 요청하는데 사용된다고 이해했습니다.

하지만 현재 구현해보고자 하는 앱(클라이언트)에서는 별도의 추가적인 서비스보다는 
Id, Pwd 를 통한 인증방식이 아닌 다른 인증 방식을 적용해보고자 사용하려고 하는 목적이기 때문에
구글 로그인은 인증 방식 중 하나일 뿐이며 추후에 필요한 것은 로그인 한 유저의 이메일 정보 수준입니다.

이 때 인증 방식을 통과한 유저일 경우 JWT 포맷으로 만료 시간은 다르지만 access token 과 refresh token 을 발급하고
(Refresh token은 별도 저장할 계획입니다.) access token에 사용자의 정보를 담아 활용하려고 한다면
이메일 로그인을 한 유저일 경우 생성하는 access token 과 oauth 로그인을 통해 발급받은 access token 을
동일한 것으로 보아야 하는지 이해가 잘 가지 않습니다.

만약 같은 의미로 보는 것이 맞다고 하면
Oauth 를 통해 유저가 로그인 했을 경우이던 이메일(id, pwd) 로그인을 했을 경우이던
유저의 정보는 access token에 담아 사용하겠지만
이메일 로그인의 경우는 access token 을 앱에서 생성하여 response 를 통해 리턴하고
Oauth 의 경우는 발급받은 access token 을 전달하여 주면 되는 것일까요?

아니면 다른 경우라고 보는 것이 맞다고 하면
Oauth 로그인으로 발급받은 access token 은 authorization/resource server 과의 소통을 위해 필요한 것이고,
앱 자체에서 사용자 정보를 사용하기 위해서 필요한 토큰은 이메일 로그인과 마찬가지로 별도로 발급해 주는 것이 맞는지 궁금합니다.

—————————————————————————————————————————

많은 자료들을 찾아보고 이해해보려고 했으나 해당 부분에 대한 도움이 되는 자료를 찾지 못해 이렇게 질문하게 되었습니다.
아직 지식이 부족해 궁금한 부분에 대한 전달이 잘 되었는지 모르겠으나 의도가 이해가 가신다면
이해할 수 있는 설명을 해주시면 대단히 감사하겠습니다.

황민호 · Accepted Answer

먼저 OAuth는 직접 사용자로 부터 직접 ID, Password 등을 통해 인증을 처리하지 않고, 기존의 구글 등 다른 웹사이트 상의 본인 정보를 이용하여 또 다른 웹사이트 또는 어플리케이션에 접근 권한을 위임하기 위한 인증 절차입니다.
2.0은 그 절차에 대한 버젼을 의미하구요.

OAuth 인증 과정 중 발급받은 AccessToken 은 OAuth 인증 서버와 상호간 인증 처리를 마치고 OAuth 서버와 통신을 위한 토큰입니다. 구글을 예로 들면 발급받은 AccessToken 으로 구글에 로그인한 본인 정보를 조회한다든지 구글에서 제공하는 API들을 사용할 수 있는거죠. 따라서 일부 서비스에서는 단순 로그인을 위한 용도로만 쓸지 (OAuth Key), 다양한 API들을 사용하는 용도로 쓸지 (App Key) 를 구분하기도 한답니다.

OAuth 인증은 보통 Id나 이메일 등 사용자의 유니크한 식별값을 획득하는 것으로 그 절차가 마무리 됩니다. 유니크한 식별값이 우리 DB상에 없다면 신규 사용자로 판단하여 가입 절차를 밟게 하거나 기존에 다른 방식의 계정이 있었다면 계정연동을 하게 하면 됩니다. 만약 우리 DB에 있다면 기존 사용자이므로 해당 사용자가 정상적으로 로그인했다고 판단하고 서비스 인증을 처리하면 됩니다. 인증관리는 인증세션을 열 수도 있고, 쿠키를 발급할 수도 있고 JWT Token 등을 발급할 수도 있습니다.

만일 JWT방식의 AccessToken을 발급하기로 했다면 이제 프론트나 별도 APP에서 우리 서비스의 API를 호출할 때 이 Access Token을 요청 헤더에 포함시켜 API를 사용할 수 있게 됩니다.

추가로 JWT 방식은 사용이 간편하고 Token의 위변조가 힘들어 많이 사용 됩니다만 단점도 있습니다. Token내 정보는 누구든지 쉽에 알 수 있기 때문에 사용자의 민감한 정보는 담으면 안됩니다. 또한 한번 발급한 Token은 만료가 되기전까지는 폐기할 수 없기 때문에 이에 따른 추가적인 다양한 대안들을 마련해야 할 수도 있습니다. 그리고 JWT Token 발급 시 사용된 SecretKey를 알아내면 악의적인 목적으로 Token을 무단을 발급하거나 위변조가 가능하므로 Vault 도입 등 시크릿키 관리에도 신경써야 합니다.

손정현 · Answer

안녕하세요!

OAuth2.0로 받은 access_token과 일반적인 id, password로 로그인해서 받은 access_token을 동일하게 취급해야하는지가 질문이신 것 같은데 맞을까요?

이 영역은 구현하기 나름인것 같습니다. 일반적으로 OAuth2.0로 받은 access_token을 서버 API 호출할때 마다 검증해서 사용할 수도 있지만, 이럴 경우 서버에서 OAuth2.0 프로바이더 쪽과 통신이 필요할 가능성이 있습니다. 질문자님처럼 OAuth2.0 방식과 일반적인 로그인이 같이 사용되는 형태라면 서버 API 호출 전용 access_token을 새롭게 내려주는 것도 방법인 것 같아요. (일반 로그인 할때 내려주는 access_token과 동일한 토큰이라고 생각해주시면 될 것 같습니다)

가장 쉬운 방법은 클라이언트 쪽에서 OAuth2.0로 로그인을 하더라도 거기서 로그인 플로우를 끝내는 것이 아니라 OAuth2.0의 access_token으로 서버를 호출한 뒤, 서버 API 전용 access_token과 refresh_token을 발급받아서 사용하는 방식이 있을 것 같네요.

쉽게 생각하면, 서버에서 사용자를 인증하는 방법으로 1. id, password, 2. OAuth2.0의 access_token 가 있고 두가지 방법 중 아무거나 서버에서 정상적으로 인증이 된다면 서버에서 서버 API 호출용 access_token과 refresh_token을 만들어서 앱(클라이언트)으로 내려주는 방식입니다. 앱에서는 이 토큰들을 잘 보관하고 있다가 서버 호출할때 토큰을 잘 전달해주면 되구요. 이후 서버에서는 API 요청이 들어오면 access_token을 검증해서 인가해주는 방법이에요. 서버 API 호출용 access_token에는 필요한 유저 정보를 담으면 될 것 같아요.

다만 이 방식도 허점이 있을 수 있습니다. 예를 들면,
- OAuth2.0으로 받은 access_token으로 서버 호출용 access_token을 발급 받았는데 OAuth2.0으로 받은 access_token의 만료 시기와 서버 호출용 access_token의 만료 시기가 다르다면 어떻게 처리할 것인가?
- OAuth2.0의 access_token이 만료되면 서버 호출용 access_token도 같이 만료 시켜줘야하는가?

이런 경우가 있을 것 같네요.

OAuth2.0에 여러가지 flow 들이 있는데, 이 부분은 대부분 OAuth2.0 중점으로 설명하고 있어서 일반적인 로그인 방식으로 받는 access_token에 대한거는 구현하기 나름인 것 같습니다.

참고하시면 좋을 것 같은 글들 첨부합니다 :)
- https://tech.kakao.com/2023/01/19/social-login/?ref=codenary
- https://auth0.com/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use