프런트 엔드의 OAuth를 사용한 인증에 성공한 후 백엔드와 대화하는 방법
작은 어플리케이션을 만들고 싶다.사용자가 몇 명 있을 겁니다.나는 나만의 사용자 시스템을 만들고 싶지 않다.어플리케이션을 oauth/oauth2.0과 통합하고 싶습니다.
프런트 엔드 애플리케이션과 oauth 2.0의 통합에는 문제가 없습니다.stackoverflow.com에도 도움이 되는 기사가 많이 있습니다.예를 들어 이 게시물은 매우 도움이 됩니다.
그런데, 프런트엔드에서 인가를 받고 나면 어떻게 해야 하나요?물론 클라이언트에 "OK, mate, user is authenticated"라는 플래그를 붙일 수도 있지만, 지금 백엔드와 어떻게 대화해야 할까요?나는 몇 가지 부탁만 할 수 없다.백엔드 - API 기능을 제공하는 일부 응용 프로그램입니다.누구나 이 API에 액세스할 수 있습니다.
그래서 어쨌든 FE와 BE 사이에 인증 시스템이 필요합니다.이 시스템은 어떻게 작동합니까?
ps 나는 영어에 문제가 있어서 구글에 문의할 수 없을지도 모른다.올바른 질문을 해주시거나, 적어도 제 질문에 대한 기사를 주세요.
업데이트
컨셉을 찾고 있어요.나는 현재의 문제에 대한 해결책을 찾고 싶지 않다.어떤 FE와 BE를 사용하는지는 중요하지 않다고 생각합니다(어쨌든 아래에 정보를 제공하겠습니다).
FE와 BE는 통신에 JSON을 사용합니다.FE는 요청을 하고 BE는 JSON 응답을 보냅니다.내 어플리케이션은 (아마도) 다음과 같은 구조를 가질 것이다.
- 프런트 엔드 - 아마 각진JS
- 백엔드 - 아마 Laravel (Laravel은 로직을 구현하며 데이터베이스도 구조에 있음)
google.com, vk.com, twitter.com 등의 "서비스 프로바이더"가 사용자 상태를 기억합니까?그리고 FE 인증에 성공하면 BE에서 사용자 상태를 물어보면 되나요?
API를 작성할 때 보안상 크게 세 가지 문제가 있습니다.
인증:구글과 같은 식별 제공자는 부분적인 해결책일 뿐이다.각 API 요청에 대해 사용자에게 로그인/ID 확인을 요구하지 않기 때문에 후속 요청에 대한 인증을 직접 구현해야 합니다.백엔드에 액세스할 수 있도록 저장해야 합니다.
- 사용자의 ID(예: 이메일)
- 사용자 토큰(생성하여 API 코드에서 확인할 수 있는 임시 토큰)
인증:백엔드는 사용자 ID를 기반으로 규칙을 구현해야 합니다.
전송 보안: HTTPS 및 만료 쿠키가 안전하고 다른 사용자가 재생할 수 없습니다.(HTTPS는 트래픽을 암호화하므로 중간자 공격을 물리치고 쿠키 만료 시 나중에 재생 공격을 물리칩니다.)
따라서 API/백엔드에는 임의의 문자열에 대한 전자 메일 검색 테이블이 있습니다.이제 사용자의 ID를 노출할 필요가 없습니다.토큰은 무의미하고 일시적입니다.
이 시스템의 흐름은 다음과 같습니다.
User-Agent IdentityProvider (Google/Twitter) Front-End Back-End
|-----------------"https://your.app.com"---------->|
|---cookies-->|
your backend knows the user or not.
if backend recognizes cookie,
user is authenticated and can use your API
기타:
if the user is unknown:
|<--"unknown"-|
|<----"your/login.js"----------+
"Do you Authorize this app?"
|<------------------+
|--------"yes"----->|
+----------auth token--------->|
|<---------/your/moreinfo.js---|
|-------access_token ---------->|
1. verify access token
2. save new user info, or update existing user
3. generate expiring, random string as your own API token
+----------->|
|<-------------- set cookie: your API token --------------------|
이제 사용자는 API를 직접 사용할 수 있습니다.
|--------------- some API request, with cookie ---------------->|
|<-------------- some reply, depends on your logic, rules ------|
편집
설명에 따라 백엔드는 ID 공급자에게 접근토큰을 확인함으로써 사용자를 인증할 수 있습니다.
예를 들어 Google은 토큰을 확인하기 위해 이 엔드포인트를 표시합니다.XYZ123:
https://www.googleapis.com/oauth2/v3/tokeninfo?id_token=XYZ123
저는 모든 답을 매우 주의 깊게 읽었고, 응답자 중 절반 이상이 문제를 완전히 놓치고 있습니다.OP는 OAuth 토큰이 서비스 프로바이더에 의해 발행된 후 FE와 BE 사이의 초기 접속을 요구합니다.
OAuth 토큰이 유효한 것을 백엔드가 어떻게 인식합니까?BE가 서비스 프로바이더에 요구를 송신해, FE에 의해서 최초로 수신된 OAuth 토큰의 유효성을 확인할 수 있는 것에 주의해 주세요.이 OAuth 키는 서비스 프로바이더만이 비밀키를 가지고 있기 때문에 복호화할 수 있습니다.키를 복호화하면 보통 사용자 이름, 이메일 등의 정보로 응답합니다.
요약:
FE는 사용자가 인가한 후 서비스 프로바이더로부터 OAuth 토큰을 받습니다.FE는 OAuth 토큰을 BE로 전달합니다.BE는 OAuth 토큰을 서비스 프로바이더에 송신하여 OAuth 토큰을 검증합니다.서비스 프로바이더는 사용자 이름/이메일 정보로 BE에 응답합니다.그런 다음 사용자 이름/이메일을 사용하여 계정을 만들 수 있습니다.
다음으로 BE가 계정을 작성한 후 BE는 OAuth 토큰의 실장을 자체 생성해야 합니다.다음으로 이 OAuth 토큰을 FE에 송신합니다.요구가 있을 때마다 FE는 헤더 내의 이 토큰을 BE로 송신합니다.BE만이 이 토큰을 검증하기 위한 비밀키를 가지고 있기 때문에 어플리케이션은 매우 안전합니다.또한 요청 시마다 BE의 OAuth 토큰을 새로 고칠 수 있으며 매번 FE에 새 키를 제공할 수 있습니다.누군가가 FE에서 OAuth 토큰을 훔쳤을 경우 BE가 이미 FE용 새로운 OAuth 토큰을 작성했기 때문에 그 토큰은 즉시 무효가 됩니다.
BE가 OAuth 토큰을 검증하는 방법에 대한 자세한 정보가 있습니다.자원 서버의 OAuth 2.0 액세스 토큰을 검증하는 방법
OAuth 컨셉으로 시작해보도록 하겠습니다.FE는 클라이언트, BE는 리소스 서버입니다.
- 클라이언트가 이미 승인되었으므로 권한 부여 서버는 클라이언트에 액세스 토큰을 부여해야 합니다.
- 클라이언트가 액세스 토큰을 사용하여 리소스 서버에 요청
- 자원 서버가 액세스토큰을 검증하고 유효한 경우 요청을 처리합니다.
액세스 토큰이란 무엇인가, 액세스 토큰은 인증 서버에 의해 발행되고 클라이언트에 부여되며 리소스 서버에 의해 인식됩니다.
액세스 토큰은 인가 정보(예: 사용자 정보, 권한 범위 만료 시간...)를 나타내는 문자열입니다.
액세스 토큰은 보안을 위해 암호화될 수 있으며 리소스 서버가 암호를 해독할 수 있는지 확인해야 합니다.
자세한 내용은 OAuth 2.0 사양 https://www.rfc-editor.org/rfc/rfc6749을 참조하십시오.
프런트 엔드에 유저·시스템은 필요 없습니다.프런트 엔드는 서버와 상호 작용하여 유효한 사용자 및 비밀번호로 토큰을 요구하는 방법일 뿐입니다.
서버가 사용자와 권한을 관리해야 합니다.
사용자 로그인 시나리오
사용자 이름과 비밀번호를 입력하여 토큰을 요구합니다.서버-API는 익명 메서드이기 때문에 요청을 수락합니다(로그인 여부에 관계없이 모든 사용자가 이 메서드를 호출할 수 있습니다.
서버는 DB(또는 일부 저장소)를 확인하고 사용자 세부 정보를 자신이 가지고 있는 세부 정보와 비교합니다.상세 내용이 일치하는 경우 서버는 사용자에게 토큰을 반환합니다.
이제 사용자는 서버가 사용자를 인식할 수 있도록 이 토큰을 임의의 요구에 따라 설정해야 합니다.토큰에는 실제로 사용자 역할, 타임스탬프 등이 저장됩니다.
사용자가 API를 통해 데이터를 요청하면 헤더에서 사용자 토큰을 가져와 사용자가 해당 메서드에 액세스할 수 있는지 여부를 확인합니다.
일반적으로는 그런 식으로 작동합니다.
을 기반으로 합니다.내 답변에 NET.하지만 대부분의 BE 라이브러리는 그렇게 작동합니다.
SSO를 위한 프로젝트를 진행 중이고 질문에 대한 이해를 바탕으로 백엔드에 엔드 포인트를 생성하여 세션을 생성할 것을 제안할 수 있습니다.클라이언트 프런트엔드가 어카운트 오너의 승인을 받고 프로바이더로부터 사용자 정보를 얻으면 백엔드 엔드 엔드 백엔드의 백엔드에 정보를 게시할 수 있습니다.end end end end는 세션을 생성하여 해당 정보를 저장하고 세션 ID(흔히 이름이 jSessionId)를 쿠키와 함께 클라이언트에 반환합니다.이것에 의해, 브라우저는, 그 이후의 모든 요구를, 인증된 유저라고 간주하는 백엔드에 보존할 수 있습니다.
로그아웃하려면 백엔드에 다른 엔드포인트를 생성하여 세션 ID를 받아들이면 백엔드가 세션 ID를 삭제할 수 있습니다.
이것이 당신에게 도움이 되길 바랍니다.
토큰을 앱 상태로 저장한 후 요청 시마다 백엔드로 전달해야 합니다.백엔드로의 전달은 백엔드의 구현 방법에 따라 헤더, 쿠키 또는 파라미터로 수행할 수 있습니다.
코드에 따라 동작하고 있는 모든 피스(내 코드가 아님)의 좋은 예를 들어주세요.다음으로 인가를 설정하는 예를 나타냅니다.Bearer TOKEN 헤더
언급URL : https://stackoverflow.com/questions/33860262/how-to-interact-with-back-end-after-successful-auth-with-oauth-on-front-end
'prosource' 카테고리의 다른 글
| 둘 이상의 항목을 선택한 경우 기본 범주를 가져오시겠습니까? (0) | 2023.02.08 |
|---|---|
| 하이차트에서 범위 및 네비게이터 기능을 사용하여 열 범위 차트를 만드는 방법은 무엇입니까? (0) | 2023.02.08 |
| SQL을 통해 Wordpress 비밀번호를 재설정하시겠습니까? (0) | 2023.02.08 |
| 각도, 컨텐츠 유형이 $http와 함께 전송되지 않습니다. (0) | 2023.02.08 |
| 워드프레스 add_meta_box() 이상함 (0) | 2023.02.08 |