⚾️ 직관일기 : 직관 기록하고 직관 승률 계산하는 서비스 개발 일지
직관일기 ⚾️ 나의 직관 승률은? happybaseball-diary.web.app 기획 아이디어 올해 야구에 빠져서 정말 직관을 많이 다녔다. 팀의 승률만큼이나 재밌는 건 내가 직관 승요인지의 여부이다. 직관 기록만
inner-stella.tistory.com
직관일기 라는 서비스 구현 과정에서 로그인 기능이 필요했기 때문에
Google Firebase에서 제공하는 Authentication 기능을 사용하기로 했다.
여러 가지 로그인 제공업체를 제공하고 있다. 기본은 이메일/비밀번호인데, 비밀번호 입력 시 암호화 등을 잘 할 자신이 없었고 이를 구현하기에는 다소 시간이 걸릴 것이라고 생각되어 소셜 로그인을 사용하기로 했다.
추후 이 서비스를 주로 홍보할 채널을 생각해보면 트위터 소셜 로그인이 적합해보였지만, 트위터 소셜 로그인을 사용하려면 트위터 개발자 계정이 필요하다. 물론 작년에 학교 과제를 하면서 인증 받아둔 계정이 있었는데, 계정명이랑 비밀번호를 까먹어서....
구글 로그인을 사용하기로 했다! ^^
OAuth란?
외부 소셜 계정으로 웹 어플리케이션에 간편하게 회원가입/로그인할 수 있게 해주는 수단이다.
웹 서비스가 사용자의 개인 정보를 구글에 요청해 대신 로그인하는 것이라고 생각하면 된다.
OAuth는 크게 3가지로 구성된다. (OAuth에서 말하는 resource는 사용자의 개인 정보)
1. 서비스 사용자 (resource owner)
- 웹 서비스를 이용하려는 사용자
- 소셜 로그인 기능을 통해 자신의 정보를 웹 서비스에 제공할 지 허용이 필요하다
2. 서비스 (client)
- resource server에게 필요한 resource를 요청하고 이에 대한 응답을 받는다
3. 소셜 로그인 기능 제공 업체 (authorization server, resource server)
- ex) Google, Kakao, Naver
- authorization server : 권한을 부여해주는 서버
- id/pw -> authorization code -> token
- access token : resource에 대한 접근 권한을 resource owner가 인가하였음을 나타내는 자격을 증명하며, 보안 상 이슈로 만료 기간이 비교적 짧다.
- refresh token : 만료 기간이 비교적 길고, refresh token이 있다면 access token이 만료될 때 이 토큰을 통해 access token을 재발급 받기 때문에 재 로그인할 필요가 없다.
- resource server : 사용자의 개인정보를 가지고 있는 서버
OAuth의 최종 목적은 Access Token을 발급 받는 것이다.
이번에 만든 서비스를 기준으로 로그인 과정을 도식화 해보았다.
(잘못 이해한 부분이 있을 수도 있으니, 틀린 부분이 있다면 댓글 남겨주세요!)
* 참고 문헌
1. https://ko.wikipedia.org/wiki/OAuth
'Dev > Web' 카테고리의 다른 글
시맨틱 태그를 쓰면 좋은 점 (0) | 2024.01.05 |
---|---|
웹 접근성 높이기 w/ 기존 프로젝트 리팩터링 (Lighthouse) (0) | 2024.01.02 |
카카오톡으로 링크 공유시 오픈 그래프 이미지 안 나올 때 (공유 디버거 사용하기) (0) | 2023.09.21 |
배포 후 React-flask cors 해결하기 (react proxy는 소용 없음) (0) | 2023.04.03 |
Mixed Content : This request has been blocked; the content must be served over HTTPS. (0) | 2023.04.03 |