oauth2 FE/BE 책임 분가

Question

Spring Security + OAuth2-Client 라이브러리를 안쓰고 직접 구현한 프로젝트들 보니 인가코드를 프론트엔드한테 받는 코드들이 많더라구요. 아래 링크를 보면 책임을 FE 또는 BE가 전적으로 맡는걸로 아는데 사진처럼 인가코드를 프론트한테 받고 토큰은 서버에서 직접 호출하는 방식은 권장사항이 아니지 않나요?https://devtalk.kakao.com/t/oauth/136448

빠른코딩 · Answer

코드는 클라에서 발급해서 주도 서버가 토큰은 꺼내오는게 좋은것 같습니다

캐티 · Answer

애초에 .. 유료 api나 할당량이 제한되어 있으면 시크릿 키를 프엔에 올리면 망하빈다. 시크릿 키를 도용하여서 남용이나 해킹에 악용될 수 있겠쩌. 이케이케 백엔드에서 처리해야 하는 부분이 있스빈다. 어플리케이션에 시크릿 키를 넣으려고 한다면 키를 찾기 어렵게 만드는 기법이 있는데 이렇다 하더라도 만능이 아니빈다.

2948284 · Answer

authorizedcode를 받고 백엔드가 쿠키에 엑세스를 박아서 리다이렉트할 수 없는 경우도 있을 수 있잖아요 ㅎㅎ 도메인 등의 이슈로. 서드파트쿠키 이슈도 있고어짜피 대다수 auth서버의 authorizedcode는 1회성이거나 엄청 짧게 설게되어있어요.프론트가 전달받아도 상관은 없습니다. 보통 fe be 분리된 환경에서 리다이렉트 자체를 프론트로 받고 그렇게 하지용. 백엔드에서 인가코드받고 인증한후 엑세스코드를 프론트에 쿠키를 잘 박아줄 수 있는 환경이시면 생각한대로 하시면 됩니다그게 아니면 그냥 프론트로 리다이렉트죠

wharup · Answer

프론트엔드는 access code를 받고, 백엔드가 access token을 받아 보관하는 건 보안적으로 매우 중요합니다.Oauth에선 네트워크 구간을 Front Channel과 Back Channel로 나눕니다. Front Channel은 사용자 브라우저가 존재하는 구간으로 덜 안전하며, 위변조의 가능성이 존재하고, Back Channel은 Authorization Server와 Client가 직접 통신하는 매우 안전한 구간입니다. 사용자나 제3자의 개입 가능성이 낮아 위변조의 위험이 적습니다.사용자가 브라우저로 Authorization Server에 로그인했을 때 Access Token을 바로 반환하면 안전하지 않은 Front Channel로 Access Token이 전달되므로 탈취 가능성이 높아집니다. 이를 방지하려고 굳이 일회성인 access code를 만들어서 Front Channel로 전달하고, 상대적으로 신뢰할 수 있는 Back Channel에 있는 백엔드 서버가 Authorization Server에서 Access token을 받아와서 내부에 보관하게 만드는게 authorization code grant type의 핵심입니다.참고로, 백엔드가 없는 앱은 모든 구성 요소가 Front Channel에 존재하므로 Access Token이 노출될 수 밖에 없으니 어쩔 수 없이 Implicit Grant Type을 만들었던거죠.

MungGaeDev · Answer

로그인정보를 기반으로 프론트에서 AAAAA 라는 인가코드를 받고백에선 AAAAA를 기반으로 BBBBB라는 Access Token을 받고api 실제 호출시엔 BBBBB를 사용합니다.https://developers.kakao.com/docs/latest/ko/kakaologin/common#login-seq위 문서의 로그인 부분에 해당합니다.프론트로 Access를 아예 안넘길수 있다는 장점이 있습니다.

oauth2 FE/BE 책임 분가

5개의 답변

Q&A 목록