Oauth2.0 소셜로그인 구현

Oauth 2.0의 4가지 프로토콜 중 Authorization code grant 방식에 대한 정리 글

Authorization Code Grant

• 권한부여를 하기 위해 자체 생성한 Authorization Code를 전달하는 방식

용어정리

• Resource: OAuth Provider로 부터 가져오고자 하는 자원
• Resource Owner: Resource의 주인. (사용자)
• OAuth Provider: 쉽게 말해 소셜로그인 기능이라면 카카오, 구글이 된다
  (인증을 담당하는 Authorization Server도 별개로 가지고 있다.)
• Authorization Server: 인증을 처리해주는 서버
• Client: Resource를 사용하기 위해 OAuth Provider에 접근하는 application

Authorization Code Grant의 Flow

Resource Owner -> Client : 로그인 페이지 요청
Resource Owner -> Authorization Server : Authorization Code 요청 (* redirect_url 함께 전달함)
Authorization Server -> Client : 코드 전달 (어떤 Resource에 접근가능한지에 대한 Scope가 있음)
Client -> Authorization Server : AccessToken 발급 요청
Authorization Server -> Client : Access Token 발급
Client -> Resource Server : AccessToken을 이용한 Resource 요청
Resource Server -> Client : Resource 전달

Session과 JWT는 공연장의 팔찌개념 (나갔다가 다시 입장할 때를 생각해보기)

 

---

시큐리티를 사용한 OAuth와 사용하지않은 OAuth의 차이 간단정리

trade-off 의 문제이다

시큐리티를 사용하면 직접 구조를 하지 않아서 기본구조의 경우엔 구현하기 더 간편함

하지만 확장성이 떨어지고.. 나처럼 시큐리티에 대한 이해도가 부족한 경우엔 추후에 발생한 에러를 관리하는게 매우 힘들것이다.

그리고 어느 특정 기능을 강제로 사용하게 되는 경우가 있을 수 있다. (state같은)

내가 직접 구조를 잘 짤 수 있다면 굳이 시큐리티를 사용할 필요는 없다.

 

---

 

나는 시큐리티를 잘 모르기에 시큐리티 없이 구현을 했는데, 확실히 구조를 짜는데에 상당한 난이도가 있었다.

 

시큐리티를 모르기에 어쩔 수 없이 사용하지 못한것이지만.. OAuth2의 기능만으로도 구현이 가능한게 오히려 더 나았을 수 있던 것 같다.

 

현재 진행하고 있는 프로젝트에선 일반회원/소셜회원기능이 두가지여서, 이 엔티티를 어떻게 효율적으로 병합시킬 수 있을까 고민을 많이했다.

 

직접 서비스를 구현할 것이 아닌 연습개념으로 시도를 했기에 구현을 목표로 코드를 작성했다.

 

테이블 하나에 소셜로그인과 일반로그인의 엔티티를 하나로 관리하는쪽을 생각했는데 단순히 난이도가 이 부분이 더 쉬울것이라고 생각했다.

 

일반로그인 시에 필요한 정보와 소셜로그인의 정보가 다르다보니 컬럼에 null을 사용하게 되었는데, 이러한것들도 선택의 문제이긴 하지만

 

왜인지 db에 null이 들어가있는 상황이 부정적으로 느껴져서 기피했다. 그런데 이런 고민은 애초에 기획했을때 rule을 정하면 아무 문제가

 

없었을 것 같다. 기능 테스트를 했을 때에 null로 인해 에러가 발생하진 않았다. 하지만 테이블의 컬럼이 불필요하게 많아져 보기에 안좋았다.

 

의견들을 들어보니 db에 null이 들어가면 index를 못탄다는 이유로 null을 기피하는 것 같다.(DB에 따라 다름)

 

사실 아직 index의 개념을 정확히 학습을 하지 못해서 이유를 납득하진 못했는데, 후에 학습할 때 한번 고민을 해봐야겠다.

 

이처럼 테이블에 컬럼이 많아지면 로우체이닝, 로우 마이그레이션으로 인해 성능저하가 발생할 수 있고 mySQL의 경우 index를 사용하더라도

 

해당 열의 전체값을 가져오기 때문에 조회시 데이터 조회비용이 늘어나는 문제가 있을 수 있다.

 

회원가입이나 로그인은 조회하는 수가 다른API보다 적을 것 같긴 하나 어쨋든 불필요한 비용이 지출되는 것이니 줄일 수 있다면 좋은거겠지..

 

 

 

어느덧 부트캠프 시작한지 3개월이 다 되어가는데, 구현을 목표로 했던 부분에서 효율, 비용적인 문제를 고민하는 내 모습을 보니 조금씩이나마

성장하고 있는 것 같다. 사실 아직 구현도 제대로 못하지만 ㅎ