RESTful 인증

https://stackoverflow.com/questions/319530

11-07-2019
|

문제

RESTful 인증은 무엇을 의미하며 어떻게 작동하나요?Google에서 좋은 개요를 찾을 수 없습니다.내가 이해한 유일한 것은 URL에 세션 키(기억)를 전달한다는 것인데, 이는 매우 잘못된 것일 수 있습니다.

해결책

RESTful 클라이언트-서버 아키텍처에서 인증을 처리하는 방법은 논쟁의 여지가 있습니다.

일반적으로 HTTP를 통한 SOA에서는 다음을 통해 이를 달성할 수 있습니다.

HTTPS를 통한 HTTP 기본 인증;
쿠키 및 세션 관리
HTTP 헤더의 토큰(예: OAuth 2.0 + JWT);
추가 서명 매개변수를 사용하여 인증을 쿼리합니다.

소프트웨어 아키텍처에 가장 잘 맞도록 이러한 기술을 조정하거나 더 잘 혼합해야 합니다.

각 인증 체계에는 보안 정책 및 소프트웨어 아키텍처의 목적에 따라 고유한 PRO 및 CON이 있습니다.

HTTPS를 통한 HTTP 기본 인증

표준 HTTPS 프로토콜을 기반으로 하는 이 첫 번째 솔루션은 대부분의 웹 서비스에서 사용됩니다.

GET /spec.html HTTP/1.1
Host: www.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

구현하기 쉽고 기본적으로 모든 브라우저에서 사용할 수 있지만 브라우저에 표시되는 끔찍한 인증 창과 같이 지속되는(여기에는 로그아웃과 같은 기능이 없음) 일부 서버 측 추가 CPU 소비와 같은 몇 가지 알려진 단점이 있습니다. 사용자 이름과 비밀번호가 (HTTPS를 통해) 서버로 전송된다는 사실(키보드 입력 중에 비밀번호를 클라이언트 측에만 유지하고 서버에 보안 해시로 저장하는 것이 더 안전해야 함) .

우리는 사용할 수 있습니다 다이제스트 인증, 그러나 다음에 취약하므로 HTTPS도 필요합니다. 밈 또는 다시 하다 공격하며 HTTP에만 해당됩니다.

쿠키를 통한 세션

솔직히 말해서 서버에서 관리되는 세션은 실제로 Stateless가 아닙니다.

한 가지 가능성은 쿠키 콘텐츠 내의 모든 데이터를 유지하는 것입니다.그리고 설계상 쿠키는 서버 측에서 처리됩니다. 실제로 클라이언트는 이 쿠키 데이터를 해석하려고 시도하지도 않습니다.연속적인 요청이 있을 때마다 서버에 다시 전달합니다.)하지만 이 쿠키 데이터는 애플리케이션 상태 데이터이므로 순수한 Stateless 세계에서는 서버가 아닌 클라이언트가 이를 관리해야 합니다.

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123

쿠키 기술 자체는 HTTP에 연결되어 있으므로 프로토콜 독립적인 IMHO여야 하는 진정한 RESTful이 아닙니다.다음에 취약합니다. 밈 또는 다시 하다 공격.

토큰(OAuth2)을 통해 부여됨

대안은 요청이 인증되도록 HTTP 헤더 내에 토큰을 넣는 것입니다.이것이 바로 OAuth 예를 들어 2.0은 그렇습니다.보다 RFC 6749:

 GET /resource/1 HTTP/1.1
 Host: example.com
 Authorization: Bearer mF_9.B5f-4.1JqM

간단히 말해서 이는 쿠키와 매우 유사하며 동일한 문제를 안고 있습니다.상태 비저장이 아니며 HTTP 전송 세부 정보에 의존하며 보안상 취약점이 많다 - MiM 및 Replay 포함 - HTTPS를 통해서만 사용됩니다.일반적으로 JWT 토큰으로 사용됩니다.

쿼리 인증

쿼리 인증은 URI의 일부 추가 매개변수를 통해 각 RESTful 요청에 서명하는 것으로 구성됩니다.보다 이 참고 기사.

이 기사에서는 다음과 같이 정의했습니다.

모든 REST 쿼리는 쿼리 매개 변수에 서명하여 인증해야 합니다 개인 자격 증명을 사용하여 소문자, 알파벳 순서로 정렬됩니다. 을 서명 토큰으로 사용합니다.서명은 URL 인코딩 전에 발생해야 합니다. 쿼리 문자열입니다.

이 기술은 아마도 Stateless 아키텍처와 더 잘 호환되며 가벼운 세션 관리(DB 지속성 대신 메모리 내 세션 사용)로 구현될 수도 있습니다.

예를 들어 다음은 위 링크의 일반 URI 샘플입니다.

GET /object?apiKey=Qwerty2010

다음과 같이 전송되어야 합니다.

GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789

서명되는 문자열은 다음과 같습니다. /object?apikey=Qwerty2010&timestamp=1261496500 서명은 API 키의 비공개 구성 요소를 사용하는 해당 문자열의 SHA256 해시입니다.

서버 측 데이터 캐싱은 항상 사용 가능합니다.예를 들어 프레임워크에서는 URI 수준이 아닌 SQL 수준에서 응답을 캐시합니다.따라서 이 추가 매개변수를 추가해도 캐시 메커니즘이 중단되지 않습니다.

보다 이 기사 JSON 및 REST를 기반으로 하는 클라이언트-서버 ORM/SOA/MVC 프레임워크의 RESTful 인증에 대한 자세한 내용을 알아보세요.HTTP/1.1뿐만 아니라 명명된 파이프 또는 GDI 메시지(로컬)를 통한 통신도 허용하므로, 헤더나 쿠키와 같은 HTTP 특정성에 의존하지 않고 진정한 RESTful 인증 패턴을 구현하려고 노력했습니다.

나중에 참고:URI에 서명을 추가하는 것은 나쁜 습관으로 보일 수 있으므로(예를 들어 http 서버 로그에 표시되므로) 완화해야 합니다.재생을 피하기 위해 적절한 TTL을 사용합니다.그러나 http 로그가 손상되면 확실히 더 큰 보안 문제가 발생하게 됩니다.

실제로는 앞으로 다가올 OAuth 2.0을 위한 MAC 토큰 인증 "토큰에 의해 부여됨" 현재 체계와 관련하여 큰 개선이 있을 수 있습니다.그러나 이는 아직 진행 중인 작업이며 HTTP 전송과 관련되어 있습니다.

결론

REST는 HTTP 기반일 뿐만 아니라 실제로는 대부분 HTTP를 통해 구현된다는 결론을 내릴 가치가 있습니다.REST는 다른 통신 계층을 사용할 수 있습니다.따라서 RESTful 인증은 Google의 답변에 관계없이 HTTP 인증의 동의어가 아닙니다.HTTP 메커니즘을 전혀 사용하지 않아야 하며 통신 계층에서 추상화되어야 합니다.그리고 HTTP 통신을 사용하는 경우 암호화하자 이니셔티브 인증 방식 외에 필수인 적절한 HTTPS를 사용하지 않을 이유가 없습니다.

다른 팁

"HTTP 인증"을 열광적으로 외치는 사람들이 REST를 사용하여 (기계 간 웹 서비스 대신) 브라우저 기반 응용 프로그램을 만들려고 시도한 적이 있는지 의심됩니다(공격하려는 의도는 없습니다. 단지 그들이 합병증에 직면한 적이 없다고 생각합니다) .

브라우저에서 볼 수 있는 HTML 페이지를 생성하는 RESTful 서비스에서 HTTP 인증을 사용하면서 발견한 문제점은 다음과 같습니다.

사용자는 일반적으로 브라우저에서 만든 보기 흉한 로그인 상자를 받게 되는데, 이는 매우 사용자 친화적이지 않습니다.비밀번호 검색, 도움말 상자 등을 추가할 수 없습니다.
로그아웃하거나 다른 이름으로 로그인하는 것은 문제입니다. 브라우저는 창을 닫을 때까지 사이트에 인증 정보를 계속 보냅니다.
타임아웃은 어렵다

이러한 점을 하나씩 다루는 매우 통찰력 있는 기사는 다음과 같습니다. 여기, 그러나 이로 인해 많은 브라우저별 자바스크립트 해커, 해결 방법 등에 대한 설명입니다.따라서 이후 버전과도 호환되지 않으므로 새 브라우저가 출시될 때마다 지속적인 유지 관리가 필요합니다.나는 그 깨끗하고 명확한 디자인을 고려하지 않고, 내 REST 배지를 친구들에게 열정적으로 보여주기 위해 많은 추가 작업과 골치 아픈 일이라고 생각합니다.

저는 쿠키가 해결책이라고 믿습니다.하지만 잠깐만요, 쿠키는 사악해요, 그렇죠?아니요, 그렇지 않습니다. 쿠키가 자주 사용되는 방식은 악합니다.쿠키 자체는 사용자가 탐색하는 동안 브라우저가 추적하는 HTTP 인증 정보와 마찬가지로 클라이언트 측 정보의 일부일 뿐입니다.그리고 이 클라이언트 측 정보는 HTTP 인증 정보와 마찬가지로 요청이 있을 때마다 서버로 전송됩니다.개념적으로 유일한 차이점은 콘텐츠 클라이언트측 상태의 이 부분은 다음에 의해 결정될 수 있습니다. 섬기는 사람 응답의 일부로.

다음 규칙을 사용하여 세션을 RESTful 리소스로 만듭니다.

ㅏ 세션 키를 사용자 ID(및 시간 초과에 대한 마지막 작업 타임스탬프)에 매핑합니다.
만약 세션 존재하면 키가 유효하다는 의미입니다.
로그인은 /sessions에 게시하는 것을 의미하며 새 키가 쿠키로 설정됩니다.
로그아웃은 /sessions/{key} 삭제를 의미합니다(오버로드된 POST를 사용하면 우리는 브라우저이고 HTML 5는 아직 갈 길이 멀다는 것을 기억하세요).
인증은 요청할 때마다 키를 쿠키로 전송하고 세션이 존재하고 유효한지 확인하여 수행됩니다.

이제 HTTP 인증과의 유일한 차이점은 클라이언트가 입력된 자격 증명에서 인증 키를 계산하는 대신 서버에서 인증 키가 생성되어 이를 계속해서 다시 보내는 클라이언트로 전송된다는 것입니다.

Converter42는 https를 사용할 때(우리는 그래야 함) 인증 정보가 비보안 연결을 통해 절대 전송되지 않도록 쿠키에 보안 플래그를 설정하는 것이 중요하다고 덧붙였습니다.좋은 점은 직접 본 적이 없다는 것입니다.

나는 이것이 잘 작동하는 충분한 솔루션이라고 생각하지만 이 체계의 잠재적 허점을 식별하기에는 보안 전문가가 충분하지 않다는 것을 인정해야 합니다. 내가 아는 것은 수백 개의 비RESTful 웹 애플리케이션이 본질적으로 동일한 솔루션을 사용한다는 것입니다. 로그인 프로토콜(PHP의 $_SESSION, Java EE의 HttpSession 등)쿠키 헤더 내용은 단순히 서버측 리소스를 처리하는 데 사용됩니다. 마치 승인 언어가 번역 리소스 등에 액세스하는 데 사용될 수 있는 것처럼 말입니다.나는 그것이 같다고 생각하지만 다른 사람들은 그렇지 않을 수도 있습니까?어떻게 생각하세요?

여기 좋은 사람들이 이 주제에 대해 이미 충분히 이야기했습니다.하지만 여기 내 2센트가 있습니다.

상호작용에는 2가지 모드가 있습니다:

인간 대 기계(HTM)
기계 대 기계(MTM)

기계는 REST API로 표현되는 공통 분모이며 행위자/클라이언트는 인간 또는 기계입니다.

이제 진정한 RESTful 아키텍처에서 무상태라는 개념은 모든 관련 애플리케이션 상태(클라이언트 측 상태를 의미)가 모든 요청과 함께 제공되어야 함을 의미합니다.관련이란 요청을 처리하고 적절한 응답을 제공하기 위해 REST API에 필요한 모든 것을 의미합니다.

Skrebbel이 위에서 지적한 것처럼 "브라우저 기반"이라는 인간 대 기계 애플리케이션의 맥락에서 이를 고려할 때 이는 브라우저에서 실행되는 (웹) 애플리케이션이 각 요청과 함께 상태 및 관련 정보를 보내야 함을 의미합니다. 백엔드 REST API를 만듭니다.

이걸 고려하세요:REST API의 데이터/정보 플랫폼 노출 자산이 있습니다.아마도 모든 데이터 큐브를 처리하는 셀프 서비스 BI 플랫폼이 있을 것입니다.그러나 (인간) 고객이 (1) 웹 앱, (2) 모바일 앱 및 (3) 일부 타사 애플리케이션을 통해 이에 액세스하기를 원합니다.결국 MTM 체인도 HTM으로 이어집니다.따라서 인간 사용자는 정보 사슬의 정점에 남아 있습니다.

처음 두 가지 경우에는 인간과 기계의 상호 작용에 대한 사례가 있으며, 정보는 실제로 인간 사용자에 의해 소비됩니다.마지막 경우에는 REST API를 사용하는 기계 프로그램이 있습니다.

인증 개념은 전반적으로 적용됩니다.REST API에 균일하고 안전한 방식으로 액세스할 수 있도록 이를 어떻게 설계하시겠습니까?제가 볼 때 2가지 방법이 있습니다.

방법-1:

처음부터 로그인이 없습니다.모든 요청은 로그인을 수행합니다.
클라이언트는 식별 매개 변수 + 특정 요청을 보냅니다. 각 요청의 매개 변수
REST API는 이를 가져와서 돌아서서 사용자 저장소를 ping합니다 (그것이 무엇이든간에) 인증을 확인합니다.
인증이 설정되면 요청을 처리합니다.그렇지 않으면 거부합니다. 적절한 HTTP 상태 코드 사용
의 모든 REST API에서 모든 요청에 대해 위의 작업을 반복합니다. 카탈로그

방법-2:

클라이언트는 인증 요청으로 시작합니다.
로그인 REST API는 이러한 모든 요청을 처리합니다.
인증 매개 변수 (API 키, uid / pwd 또는 선택) 사용자 저장소(LDAP, AD 또는 MySQL DB 등)에 대한 인증을 확인합니다.
확인되면 인증 토큰을 생성하여 클라이언트/호출자
그런 다음 호출자는이 인증 토큰 + 요청 특정 매개 변수를 보냅니다. 로그아웃할 때까지 또는 임대가 만료될 때까지 다른 비즈니스 REST API에 대한 모든 후속 요청

분명히 Way-2에서는 REST API에 토큰을 유효한 것으로 인식하고 신뢰하는 방법이 필요합니다.로그인 API가 인증 확인을 수행했으므로 카탈로그의 다른 REST API에서 "발렛 키"를 신뢰해야 합니다.

물론 이는 인증 키/토큰을 REST API 간에 저장하고 공유해야 함을 의미합니다.이 공유되고 신뢰할 수 있는 토큰 저장소는 무엇이든 로컬/연합일 수 있으므로 다른 조직의 REST API가 서로를 신뢰할 수 있습니다.

그러나 나는 빗나갔다.

요점은 모든 REST API가 신뢰 관계를 만들 수 있도록 "상태"(클라이언트의 인증 상태에 대한)를 유지하고 공유해야 한다는 것입니다.Way-1인 이 작업을 수행하지 않으면 들어오는 모든 요청에 대해 인증 작업을 수행해야 한다는 점을 받아들여야 합니다.

인증 수행은 리소스 집약적인 프로세스입니다.들어오는 모든 요청에 대해 사용자 저장소에 대해 SQL 쿼리를 실행하여 uid/pwd 일치를 확인한다고 상상해 보세요.또는 해시 일치를 암호화하고 수행합니다(AWS 스타일).그리고 구조적으로 모든 REST API는 공통 백엔드 로그인 서비스를 사용하여 이를 수행해야 할 것 같습니다.그렇지 않으면 인증 코드를 여기저기에 흩뿌리게 되기 때문입니다.큰 혼란.

따라서 레이어가 많을수록 대기 시간도 늘어납니다.

이제 Way-1을 선택하여 HTM에 지원하세요.당신의 (인간) 사용자는 모든 요청에 대해 uid/pwd/hash 등을 보내야 하는지 정말로 신경쓰나요?아니요, 매초마다 인증/로그인 페이지를 표시하여 그녀를 괴롭히지 않는 한 말이죠.그렇다면 고객이 있기를 바랍니다.따라서 당신이 할 일은 로그인 정보를 클라이언트 측, 브라우저의 시작 부분에 저장하고 요청이 있을 때마다 보내는 것입니다.(인간) 사용자의 경우 이미 로그인했으며 "세션"을 사용할 수 있습니다.그러나 실제로는 모든 요청에 대해 인증을 받습니다.

Way-2와 동일합니다.귀하의 (인간) 사용자는 결코 눈치 채지 못할 것입니다.그래서 해를 끼치 지 않았습니다.

Way-1을 MTM에 적용하면 어떨까요?이 경우 기계이기 때문에 요청할 때마다 인증 정보를 제출하도록 요청하여 이 사람을 지루하게 만들 수 있습니다.아무도 신경쓰지 않아요!MTM에서 Way-2를 수행해도 특별한 반응이 발생하지 않습니다.빌어먹을 기계야.덜 신경쓰일 수도 있어요!

따라서 실제로 질문은 귀하의 필요에 맞는 것입니다.무국적에는 지불해야 할 대가가 있습니다.가격을 지불하고 계속 진행하세요.순수주의자가 되고 싶다면 그에 대한 대가도 치르고 계속 나아가십시오.

결국 철학은 중요하지 않습니다.정말 중요한 것은 정보의 발견, 표현, 소비 경험입니다.사람들이 당신의 API를 좋아한다면 당신은 일을 한 것입니다.

다음은 진정으로 완전히 편안한 인증 솔루션입니다.

인증 서버에서 공개/개인 키 쌍을 만듭니다.
공개 키를 모든 서버에 배포하십시오.
클라이언트가 인증 할 때 :

3.1. 다음이 포함 된 토큰을 발행하십시오.
- 만료 시간
- 사용자 이름 (선택 사항)
- 사용자 IP (선택 사항)
- 암호 해시 (선택 사항)
3.2. 개인 키로 토큰을 암호화합니다.

3.3. 암호화 된 토큰을 사용자에게 다시 보냅니다.
사용자가 API에 액세스하면 인증 토큰을 전달해야합니다.
서버는 인증 서버의 공개 키를 사용하여 토큰을 해독하여 토큰이 유효한지 확인할 수 있습니다.

이것은 무국적/편안한 인증입니다.

비밀번호 해시가 포함 된 경우 사용자는 인증 토큰과 함께 암호화되지 않은 암호를 보냅니다. 서버는 암호가 해시를 비교하여 인증 토큰을 만드는 데 사용 된 비밀번호와 일치하는지 확인할 수 있습니다. HTTPS와 같은 것을 사용하는 안전한 연결이 필요합니다. 클라이언트 측의 JavaScript는 사용자의 비밀번호를 얻고 메모리 또는 쿠키에 IT 클라이언트를 저장할 수 있습니다. 공공의 열쇠.

당신에게 솔직히 말해서 나는 여기서 위대한 대답을 보았지만 조금 귀찮게하는 것은 누군가가 전체 무국적 개념을 독단적 인 곳으로 가져갈 때입니다. 그것은 순수한 oo를 받아들이고 싶었던 오래된 스몰 토크 팬들을 생각 나게합니다. 나에게 휴식을주세요.

편안한 접근 방식은 인생을 편하게하고 세션의 오버 헤드와 비용을 줄이고, 현명한 일이기 때문에 그것을 따르도록 노력하지만, 당신이 징계 (모든 징계/지침)을 따르는 순간은 극단적 인 곳으로 이어집니다. 더 이상 의도 한 혜택을 제공하지 않으면 잘못하고 있습니다. 오늘날 최고의 언어 중 일부에는 기능적 프로그래밍 및 객체 방향이 모두 있습니다.

문제를 해결하는 가장 쉬운 방법이 인증 키를 쿠키에 저장하고 HTTP 헤더로 보내는 것이면 학대하지 마십시오. 세션이 무겁고 커질 때 나쁘다는 것을 기억하십시오. 모든 세션이 열쇠를 포함하는 짧은 문자열이라면 큰 문제는 무엇입니까?

나는 의견으로 수정을 받아 들일 수 있지만 서버에서 큰 해시 사전을 유지하지 않기 위해 우리의 삶을 비참하게 만드는 요점을 보지 못합니다.

무엇보다도 편안한 웹 서비스입니다 무국적 (즉, 즉, 세션리스). 따라서 편안한 서비스에는 세션이나 쿠키 개념이 없으며 관련된 개념이 없어야합니다. Restful Service에서 인증 또는 승인을 수행하는 방법은 RFC 2616 HTTP 사양에 정의 된 HTTP 인증 헤더를 사용하는 것입니다. 모든 단일 요청에는 HTTP 인증 헤더가 포함되어야하며 요청은 HTTP (SSL) 연결을 통해 전송되어야합니다. 이것은 인증을 수행하고 HTTP RESTFUL WEB SERVICES에서 요청의 승인을 확인하는 올바른 방법입니다. Cisco Systems의 Cisco Prime Performance Manager 응용 프로그램을위한 Restful 웹 서비스를 구현했습니다. 그리고 그 웹 서비스의 일환으로 인증/승인도 구현했습니다.

루벤스 고메.

일반적으로 휴식의 모든 제약 내에서 수행되는 세션이없는 인증을 참조하는 데 사용되기 때문에 "세션 키"에 관한 것이 아닙니다. 각 요청은 자체 설명이며 서버 측 애플리케이션 상태없이 자체적으로 요청을 승인하기에 충분한 정보를 전달합니다.

이것에 접근하는 가장 쉬운 방법은 HTTP의 내장 인증 메커니즘으로 시작하는 것입니다. RFC 2617.

@skrebel이 언급 한 '매우 통찰력있는'기사 ( http://www.berenddeboer.net/rest/authentication.html )는 복잡하지만 실제로 깨진 인증 방법에 대해 논의합니다.

페이지를 방문하려고 시도 할 수 있습니다 (인증 된 사용자에게만 볼 수 있어야 함). http://www.berenddeboer.net/rest/site/authenticated.html 로그인 자격 증명없이.

(죄송합니다. 답변에 대해 언급 할 수 없습니다.)

나는 휴식과 인증이 단순히 섞이지 않는다고 말할 것입니다. 휴식은 무국적이지만 '인증 된'은 상태입니다. 둘 다 같은 레이어로 가질 수 없습니다. 당신이 편안한 옹호자이고 주에 눈살을 찌푸리면 HTTPS와 함께 가야합니다 (즉, 보안 문제를 다른 계층으로 맡기십시오).

RESTFUL 인증은 요청의 매개 변수로 인증 토큰을 통과하는 것이 포함된다고 생각합니다. 예는 API의 Apikeys를 사용하는 것입니다. 쿠키 또는 HTTP 인증의 사용이 자격이 있다고 생각하지 않습니다.

2019 년 16 월 16 일 업데이트

아래 앞에서 언급 한 접근 방식은 본질적으로 "자원 소유자 암호 자격 증명"보조금 유형입니다. oauth2.0. 이것은 일어나서 달리기 쉬운 방법입니다. 그러나이 접근 방식으로 조직의 모든 응용 프로그램은 자체 인증 및 승인 메커니즘으로 끝날 것입니다. 권장 접근법은 "인증 코드"보조금 유형입니다. 또한 아래의 이전 답변에서 인증 토큰을 저장하기 위해 Browser LocalStorage를 추천했습니다. 그러나 나는 쿠키 가이 목적에 적합한 옵션이라고 믿게되었습니다. 저의 이유, 승인 코드 보조금 유형 구현 접근 방식, 보안 고려 사항 등을 자세히 설명했습니다. 이 stackoverflow 답변.

다음과 같은 접근 방식은 REST 서비스 인증에 사용될 수 있다고 생각합니다.

인증을 위해 사용자 이름과 비밀번호를 수락하기 위해 로그인 RESTFUL API를 만듭니다. HTTP Post 방법을 사용하여 캐싱 및 SSL이 성공적인 인증시 보안을위한 SSL을 방지합니다. API는 두 개의 JWT를 반환합니다. 하나의 액세스 토큰 (짧은 유효성, 30 분) 및 하나의 새로 고침 (더 긴 유효성, 24 시간)을 반환합니다.
클라이언트 (웹 기반 UI)는 JWTS를 로컬 스토리지에 저장하고 모든 후속 API 호출에서 "Authorization : Bearer #ACCESS TOKEN"헤더에서 액세스 토큰을 통과합니다.
API는 서명 및 만료 날짜를 확인하여 토큰의 유효성을 확인합니다. 토큰이 유효 한 경우 사용자 (사용자 이름으로 JWT의 "Sub"주장을 해석)가 캐시 조회를 통해 API에 액세스 할 수 있는지 확인하십시오. 사용자가 API에 액세스 할 권한이있는 경우 비즈니스 로직을 실행하십시오.
토큰이 만료되면 API는 HTTP 응답 코드 400을 반환합니다.
400/401을 받으면 클라이언트는 "Authorization : Bearer #Refresh Token"헤더에서 새로 고침 토큰으로 다른 REST API를 호출하여 새로운 액세스 토큰을 얻습니다.
새로 고침 토큰으로 통화를 받으면 서명과 만료 날짜를 확인하여 새로 고침 토큰이 유효한지 확인하십시오. 새로 고침 토큰이 유효한 경우 DB에서 사용자의 액세스 오른쪽 캐시를 새로 고치고 새 액세스 토큰을 반환하고 토큰을 새로 고치십시오. 새로 고침 토큰이 유효하지 않은 경우 HTTP 응답 코드 400을 반환합니다.
새 액세스 토큰 및 새로 고침 토큰이 반환되면 2 단계로 이동하십시오. HTTP 응답 코드 400이 반환되면 클라이언트는 새로 고침 토큰이 만료되었다고 가정하고 사용자의 사용자 이름과 비밀번호를 묻습니다.
로그 아웃의 경우 로컬 스토리지를 제거하십시오

이 접근법을 통해 우리는 30 분마다 사용자 별 액세스 세부 사항을 사용하여 캐시를로드하는 비싼 작업을 수행하고 있습니다. 따라서 액세스가 취소되거나 새 액세스가 승인되면 반영하는 데 30 분이 걸리거나 로그 아웃 한 다음 로그인이 뒤 따릅니다.

그것이 그렇게하는 방법입니다. 로그인에는 OAUTH 2.0 사용.

OAUTH를 지원하는 한 다른 인증 방법을 사용하여 Google의 다른 인증 방법을 사용할 수 있습니다.

내 이해 로이 질문에 답하기 위해 ...

시스템에서 사용자를 실제로 추적하거나 관리 할 필요가 없도록 REST를 사용하는 인증 시스템. 이것은 HTTP 메소드 게시물, Get, Put, Delete를 사용하여 수행됩니다. 우리는이 4 가지 방법을 취하고 데이터베이스 상호 작용 측면에서 작성, 읽기, 업데이트, 삭제로 생각합니다 (그러나 웹에서는 게시물을 사용하고 앵커 태그가 현재 지원하기 때문에 얻습니다). 따라서 게시물을 처리하고 CRUD (Create/Read/Update/Delete)로 가져 오면 웹 애플리케이션에서 경로를 설계하여 달성하는 CRUD의 동작을 추론 할 수 있습니다.

예를 들어, Ruby on Rails 응용 프로그램에서 방문에 로그인 한 사용자가 방문하는 경우 웹 앱을 구축 할 수 있습니다. http://store.com/account/logout 그러면 해당 페이지의 얻기가 사용자가 로그 아웃을 시도하는 것으로 볼 수 있습니다. Rails 컨트롤러에서는 사용자를 로그 아웃하고 홈페이지로 다시 보내는 작업을 작성합니다.

로그인 페이지에서 얻는 것은 양식을 산출합니다. 로그인 페이지의 게시물은 로그인 시도로보고 게시물 데이터를 사용하여 로그인하는 데 사용됩니다.

나에게는 데이터베이스 의미에 매핑 된 HTTP 메소드를 사용한 다음 세션 ID 또는 트랙 세션을 전달할 필요가 없다는 점을 염두에두고 인증 시스템을 구축하는 관행입니다.

나는 아직도 배우고있다. 만약 당신이 내가 틀렸다고 말한 것을 발견했다면 나를 바로 잡으십시오. 더 많은 것을 배우면 여기에 다시 게시하십시오. 감사.

열쇠 등록이 적절한 구속력과 관련된 공개 키 인증 사용을 사용하여 공개 키가 비 응답을 보장하는 방식으로 할당 된 개인에게 구속력이되도록합니다.

보다 http://en.wikipedia.org/wiki/public_key_infrastructure . 적절한 PKI 표준을 따르는 경우 도난 키를 부적절하게 사용하는 사람 또는 대리인은 식별하고 잠겨 있습니다. 에이전트가 인증서를 사용해야하는 경우 바인딩이 꽤 빡빡 해집니다. 영리하고 빠르게 움직이는 도둑은 탈출 할 수 있지만 더 많은 부스러기를 남깁니다.

웹 애플리케이션 보안에 유효한 팁

응용 프로그램을 확보하려면 그런 다음 HTTP 대신 HTTPS를 사용하여 시작해야합니다., 이를 통해 사용자와 사용자에게 전송 된 데이터 스니핑을 방지하는 사용자 간의 보안 채널을 생성하고 데이터 교환을 기밀로 유지하는 데 도움이됩니다.

JWTS (JSON Web Tokens)를 사용하여 RESTFUL API를 보호 할 수 있습니다., 이것은 서버 측 세션과 비교할 때 많은 이점이 있습니다. 이점은 주로 다음과 같습니다.

1- API 서버가 각 사용자에 대한 세션을 유지할 필요가 없으므로 더 확장 가능합니다 (세션이 많을 때 큰 부담이 될 수 있음).

2- JWTS는 자체적으로 포함되어 있으며 예를 들어 사용자 역할을 정의하는 청구 및 날짜 및 만료 날짜에 액세스하고 발행 할 수있는 내용 (JWT가 유효하지 않음)

3-로드 밸런서를 가로 질러 처리하기 쉽고 여러 API 서버가있는 경우 세션 데이터를 공유하거나 서버를 구성하여 서버를 동일한 서버로 라우팅하기 위해 서버를 구성 할 필요가 없으므로 JWT로 요청할 때마다 인증 할 수 있습니다. & 승인

4- DB에 대한 압력이 적고 각 요청에 대한 세션 ID 및 데이터를 지속적으로 저장 및 검색 할 필요는 없습니다.

5- JWT에 서명하기 위해 강력한 키를 사용하는 경우 JWTS를 조작 할 수 없으므로 사용자 세션을 확인하지 않고 요청과 함께 전송 된 JWT의 청구를 신뢰할 수 있으며 승인되었는지 여부를 신뢰할 수 있습니다. , 당신은 JWT를 확인할 수 있으며,이 사용자가 누구와 무엇을 할 수 있는지 알 수 있습니다.

많은 라이브러리는 대부분의 프로그래밍 언어에서 JWT를 생성하고 검증하는 쉬운 방법을 제공합니다. 예 : Node.js에서 가장 인기있는 것은 IS 중 하나입니다. JSONWEBTOKE

REST API는 일반적으로 서버를 무국적으로 유지하는 것을 목표로하므로 JWT는 해당 개념과 더 호환됩니다. 각 요청이 자체적으로 포함 된 승인 토큰과 함께 전송되면 (JWT) 서버가 사용자와 그의 역할을 기억할 수 있도록 서버를 상태로 유지하는 세션과 비교하여 사용자 세션을 추적해야하지 않으면 세션도 널리 사용되며 프로슈를 보유하고 있으며 원하는 경우 검색 할 수 있습니다.

주목해야 할 중요한 사항 중 하나는 HTTPS를 사용하여 고객에게 JWT를 안전하게 전달하고 안전한 장소 (예 : 로컬 스토리지)에 저장해야한다는 것입니다.

JWT에 대해 자세히 알아볼 수 있습니다 이 링크에서

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow