먼저 OAuth는 직접 사용자로 부터 직접 ID, Password 등을 통해 인증을 처리하지 않고, 기존의 구글 등 다른 웹사이트 상의 본인 정보를 이용하여 또 다른 웹사이트 또는 어플리케이션에 접

먼저 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 도입 등 시크릿키 관리에도 신경써야 합니다.