[인증 / 보안] - OAuth

 OAuth

인증을 중개해주는 메커니즘

• 보안된 리소스에 액세스하기 위해 클라이언트에게 권한을 제공하는 프로세스를 단순화하는 프로토콜
• 사용자가 이미 사용하고 있는 서비스가 다른 서비스에 사용자가 인증을 할 수 있도록 중개해준다.
• 대표적인 예
  • 소셜 로그인 인증 방식
    • 정보를 입력하지 않고 이미 사용자 정보를 가지고 있는 웹 서비스에서 사용자의 인증을 대신 해주고, 접근 권한에 대한 토큰을 발급
    • 정보를 해당 사이트에 직접적으로 노출하는 것이 아니기때문에 더 안전함

 

🤝 OAuth 작동 메커니즘

📍 OAuth의 주체

Resource Owner

• OAuth 인증을 통해 소셜 로그인을 하고싶은 사용자
• Resource
  • 사용자의 이름, 전화번호 등의 정보

Resource Server & Authorization Server

• Resource Server
  • 이미 사용중인 서비스의 서버 중 사용자의 정보를 저장하고 있는 서버
• Authorization Server
  • 이미 사용중인 서비스의 서버 중 인증을 담당하는 서버

Application

• 사용자가 소셜 로그인을 활용해 이용하고자하는 새로운 서비스
• 경우에 따라 Client와 Server로 세분화해서 지칭

---

📍 OAuth 인증 방식의 종류와 흐름

OAuth 인증 방식에는 여러 가지가 있다.

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

1. Implicit Grant Type

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

하지만 소셜 로그인에서 Implicit Grant Type은 잘 사용하지 않는다.

기존 서비스에 로그인만 되어있으면 새로운 서비스에 바로 액세스 토큰을 내어줌으로 보안성이 조금 떨어지기 때문이다.

➡︎ 보통은 인증 단계를 한 단계 추가한 Authorization Code Grant Type을 주로 사용한다.

 

 

2. Authorization Code Grant Type

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

Authorization Code를 사용한 인증 단계가 추가로 있기 때문에 비교적 더 안전하다. 또한, 토큰을 Application의 Client에 노출시키지 않고 Server에서만 관리하도록 만들 수도 있기 때문에 소셜 로그인을 구현하는 방식의 선택지가 늘어나게 된다.

하지만, 새로운 서비스를 이용하다가 액세스 토큰이 만료 되었을 때마다 이 과정을 거쳐 액세스 토큰을 다시 발급 받아야 한다면 사용자 편의성에 있어서는 좋지 않다.

→ 액세스 토큰을 발급해 줄 때 리프레시 토큰을 같이 발급해 주기도 한다.

리프레시 토큰을 사용해서 액세스 토큰을 받아오는 인증 방식을 Refresh Token Grant Type이라고 한다.

 

3. Refresh Token Grant Type

• Authorization Server로 리프레시 토큰을 보내주면
• Authorization Server는 리프레시 토큰을 검증한 다음 액세스 토큰을 다시 발급해준다.
• Application은 다시 발급 받은 액세스 토큰을 사용해서 Resource Server에서 사용자의 정보를 받아온다.

---

🤝 OAuth의 장점

1. 쉽고 안전하게 새로운 서비스를 이용할 수 있다.

사용자는 특정 사이트에 아이디, 비밀번호, 이름, 전화 번호 등의 정보를 일일이 입력하지 않아도 클릭 몇 번 만으로 가입할 수 있어 편리함

정보를 해당 서비스에 직접 노출하는 것이 아니기 때문에 직접 가입하는 것보다 더 안전함

Application의 입장에서도 회원 정보 유출의 위험성에서 부담을 덜 수 있음

2. 권한 영역을 설정할 수 있다.

OAuth 인증을 허가한다고 새로운 서비스가 사용중이던 서비스의 모든 정보에 접근이 가능한 것은 아니다.

→ 사용자는 원하는 정보에만 접근을 허락할 수 있어 안전함

OAuth 설정 페이지에서 Application에서 필요한 정보를 선택할 수 있다.

→ 사용자는 이 중 원하는 정보만 선택적으로 제공할 수 있음