OAuth

대중적인 소셜 로그인 인증 방식은 OAuth 2.0라는 기술을 바탕으로 구현된다.

인증을 중개해 주는 메케니즘이다.
이미 사용자 정보를 가지고 있는 웹 서비스(Naver, Kakao, Google, Github 등)에서 사용자의 인증을 대신해 주고, 접근 권한에 대한 토큰을 발급한 후, 이를 이용해 내 서버에서 인증이 가능해진다.

개발자는 신규 회원가입이나 회원관리를 신경 쓰지 않아도 되기 때문에 사용자와 기업 모두 소셜 로그인 선호한다.

OAuth 인증 방식의 종류와 흐름

• Grant Type: Authorization Server에서 Access Token을 받아오는 방식

Implicit Code Grant Type

1. 사용자가 Application에 접속한다.
2. Application에서 Authorization Server로 인증 요청을 보낸다.
3. Authoirzation Server는 유효한 인증 요청인지 확인한 후 Access Token을 발급한다.
4. Authorization Server에서 Application으로 Access Token을 전달한다
5. Application은 발급받은 Access Token을 담아 Resource Server로 사용자의 정보를 요청한다.
6. Resource Server는 Application에게서 전달받은 Access Token이 유효한지 확인한다.
7. 유효한 토큰이라면, Application이 요청한 사용자의 정보를 전달한다.

잘 사용하지 않는다. 기존 서비스에 로그인만 되어있다면 새로운 서비스에 바로 Access Token을 내어주기 때문에 보안성이 떨어진다

Authorization Code Grant Type

위에 방식에서 Authorization Code 인증을 추가한 방식이다.

1. 사용자가 Application에 접속한다.
2. Application에서 Authorizaiton Server로 인증요청을 보낸다.
3. Authorization Server는 유효한 인증 요청인지 확인한 후 Authorization Code를 발급한다.
4. Authorization Server에서 Application으로 Authorizaiton Code를 전달한다.
5. Application이 발급받은 Authorizaiton Code를 Authorization Server로 전달한다.
6. Authorizaiont Server는 유효한 Authorization Code인지 확인한 후 Access Token을 발급한다.
7. Authorization Server에서 Application으로 Access Token을 전달한다.
8. Application은 발급받은 Access Token을 담아 Resource Server로 사용자의 정보를 요청한다.
9. Resource Server는 Application에게서 전달 받은 Access Token이 유효한지 확인한다.
10. 유요한 토큰이라면, Application이 요청한 사용자의 정보를 전달한다.

외부의 Authorization Server에서 우리가 사용하려는 애플리케이션에 Access Token을 무작정 발급하기 보다는 Authorization Code를 보내서 한번 더 확인 해보는 과정을 거친다. Authorization Code가 확인이 되면 Access Token을 발급해준다. 이 Access Token으로 다시 한번 전달해서 확인받고 사용자 정보를 받아온다.

하지만 이 Access Token이 만료가 되면 이 과정을 다시 한번 거쳐야 한다.
사용자의 편의성에 있어서 좋지 않을 것이다.

Refresh Token Grant Type

1. 애플리케이션이 Refresh Token을 Authorization server에 전달한다.
2. Refresh Token을 확인을 하고 Access Token을 Application에 전달한다.
3. Application에서 받은 Access Token을 Resource Server에 전달한다.
4. Resource Server에서 Access Token이 유효한지 확인한다.
5. Access Token이 유효하면 사용자 정보를 Application에 전달한다.

마무리

궁금한 점이 생겼었다. 만약 Authorization Code를 받으면 클라이언트 사이드에서 직접 Resource Server로 사용자 정보를 요청하면 안되는가에 대한 궁금증이었다. 보안과 안정성에서 문제가 생긴다. 프론트엔드에서 인증 코드를 직접 보내면, 해당 코드는 네트워크를 통해 악의적인 공격자에게 노출될 수 있다.

그래서 서버를 거쳐서 인증 코드를 보내는 방식은 중간에 암호화된 통신 채널을 사용하여 보완을 강화한다. 프론트엔드는 인증 코드를 서버에 전달하고, 서버는 인증 코드를 사용하여 인증 서버로부터 액세스 토큰(access token)을 안전하게 요청한다. 이 과정에서 서버 간의 통신은 SSL/TLS와 같은 암호화된 연결을 통해 이루어지므로, 인증 코드가 악의적인 공격자에게 노출되더라도 암호화된 상태로 전송되어 계정 보안을 유지할 수 있다.