토큰 기반 인증의 의미를 이해하고 싶습니다. 인터넷을 검색했지만 이해할만한 것을 찾을 수 없습니다.
답변:
긴 기사의 핵심 문장을 인용하여 여기에 잘 설명되어 있다고 생각합니다 .
토큰 기반 인증 시스템의 기본 개념은 간단합니다. 사용자가 사용자 이름과 비밀번호를 사용하지 않고 특정 리소스를 가져올 수있는 토큰을 얻기 위해 사용자 이름과 비밀번호를 입력 할 수 있도록합니다. 토큰이 확보되면 사용자는 특정 사이트에 대한 액세스를 제공하는 토큰을 원격 사이트에 제공 할 수 있습니다.
즉, 인증을 위해 한 수준의 간접 성을 추가합니다. 보호 된 각 리소스에 대해 사용자 이름과 비밀번호로 인증 할 필요없이 사용자는 한 번만 (한정된 기간의 세션 내에서) 인증하고 시간 제한 토큰을 얻습니다. 세션 동안 추가 인증을 위해 해당 토큰을 사용합니다.
장점은 많습니다 - 그들이 제한된 시간과 자원의 제한된에 대한 신뢰에 기꺼이 다른 자동화 된 시스템에 그것을 얻을 일단 예를 들어, 사용자는 토큰을 통과 할 수 있지만 것 없는 기꺼이 자신의 사용자 이름과 비밀번호를 신뢰해야합니다 (즉, 비밀번호가 변경 될 때까지 영원히 또는 최소한 액세스 할 수있는 모든 리소스로).
여전히 확실하지 않은 내용이 있으면 100 % 명확하지 않은 내용을 명확하게 설명하도록 질문을 수정하십시오. 추가 도움을 드릴 수 있습니다.
에서 Auth0.com
토큰 기반 인증은 각 요청에서 서버로 전송되는 서명 된 토큰에 의존합니다.
토큰 기반 접근 방식의 이점은 무엇입니까?
도메인 간 / CORS : 쿠키 + CORS는 다른 도메인에서 잘 작동하지 않습니다. 토큰 기반 접근 방식을 사용하면 HTTP 헤더를 사용하여 사용자 정보를 전송하므로 모든 도메인의 모든 서버에서 AJAX 호출을 수행 할 수 있습니다.
상태 비 저장 (일명 서버 측 확장 성) : 세션 저장소를 유지할 필요가 없으며 토큰은 모든 사용자 정보를 전달하는 독립적 인 엔티티입니다. 나머지주는 클라이언트 측의 쿠키 또는 로컬 스토리지에 있습니다.
CDN : CDN (예 : 자바 스크립트, HTML, 이미지 등)에서 앱의 모든 자산을 제공 할 수 있으며 서버 측은 API 일뿐입니다.
디커플링 : 특정 인증 체계에 묶여 있지 않습니다. 토큰은 어느 곳에서나 생성 될 수 있으므로 이러한 호출을 인증하는 단일 방법으로 어디서나 API를 호출 할 수 있습니다.
모바일 지원 : 네이티브 플랫폼 (iOS, Android, Windows 8 등)에서 작업을 시작할 때 토큰 기반 접근 방식을 사용하는 경우 쿠키가 이상적이지 않습니다.
CSRF : 쿠키에 의존하지 않기 때문에 교차 사이트 요청으로부터 보호 할 필요가 없습니다 (예 : 사이트가없는 경우 POST 요청을 생성하고 기존 인증 쿠키를 재사용 할 수 없음). ).
성능 : 여기서는 하드 퍼포먼스 벤치 마크를 제시하지 않지만 네트워크 왕복 (예 : 데이터베이스에서 세션 찾기)은 HMACSHA256을 계산하여 토큰의 유효성을 검사하고 내용을 구문 분석하는 것보다 시간이 더 걸릴 수 있습니다.
A token는 Server X만들 수 있었을 수있는 특정 데이터이며 특정 사용자를 식별하기에 충분한 데이터를 포함합니다.
당신은 당신의 로그인 정보를 제시하고 요청할 수 있습니다 Server XA에 대한 token; 그런 다음 사용자를 제시 token하고 Server X사용자 별 작업을 수행 하도록 요청할 수 있습니다 .
Token암호화 분야에서 다양한 기술의 다양한 조합과 광범위한 보안 연구 분야의 의견을 통해 만들어집니다. 자신 만의 token시스템을 만들어 나가기로 결정했다면 정말 똑똑 할 것입니다.
토큰은 서버가 생성 한 데이터이며 특정 사용자 및 토큰 유효성을 식별하기위한 정보를 포함합니다. 토큰에는 사용자 정보와 사용자 이름과 비밀번호를 직접 전달하는 대신 인증을 지원하는 모든 방법으로 서버에 전달할 수있는 특수 토큰 코드가 포함됩니다.
토큰 기반 인증은 서버에서 제공하는 보안 토큰을 사용하여 서버, 네트워크 또는 기타 보안 시스템에 로그인을 시도하는 사용자를 인증하는 보안 기술입니다.
사용자가 보안 토큰을 전달하여 유효한 사용자임을 서버에 증명할 수 있으면 인증에 성공한 것입니다. 서비스는 보안 토큰의 유효성을 검사하고 사용자 요청을 처리합니다.
서비스에서 토큰의 유효성을 검사 한 후에는 클라이언트에 대한 보안 컨텍스트를 설정하는 데 사용되므로 서비스는 후속 사용자 요청에 대한 권한 결정 또는 감사 활동을 수행 할 수 있습니다.
토큰 기반 (보안 / 인증)
액세스 권한을 증명하기 위해서는 먼저 토큰을 받아야합니다. 실제 시나리오에서 토큰은 건물에 대한 액세스 카드 일 수 있으며 집 열쇠의 열쇠가 될 수 있습니다. 사무실의 키 카드 나 집의 키를 검색하려면 먼저 자신의 신원을 증명해야하며 실제로 해당 토큰에 액세스 할 수 있는지 확인해야합니다. 누군가에게 당신의 ID를 보여 주거나 비밀 암호를주는 것만 큼 간단 할 수 있습니다. 사무실에 액세스해야한다고 상상해보십시오. 보안 실로 내려 가서 신분증을 보여 주면 건물에 들어갈 수있는이 토큰을줍니다. 이제 토큰을 가지고있는 한 건물 내에서 원하는 모든 것을 할 수있는 무제한 액세스 권한을 갖습니다.
토큰 기반 보안의 이점은 무엇입니까?
안전하지 않은 API를 다시 생각하면, 우리가 원하는 것은 우리가하고 싶은 모든 것을 위해 암호를 제공해야한다는 것이 었습니다.
상상 해봐사무실에서 출입 할 때마다 출입문 옆에 앉아있는 모든 사람에게 암호를 제공해야합니다. 그것은 사무실에있는 모든 사람이 우리의 암호를 가지고 우리를 가장 할 수 있다는 것을 의미하기 때문에 꽤 나쁩니다. 대신 우리는 암호와 함께 토큰을 검색하지만 한 사람으로부터 토큰을 검색합니다. 그런 다음 건물 내부에서 원하는 위치에이 토큰을 사용할 수 있습니다. 물론 토큰을 잃어버린 경우 다른 사람이 비밀번호를 알고있는 것과 같은 문제가 발생하지만 토큰을 잃어버린 경우 액세스를 취소 할 수 있는지, 아니면 토큰을 잃을 수 있는지와 같은 방식으로 연결됩니다 24 시간 이상 거주하지 않아야하므로 다음날 사무실에 오면 ID를 다시 표시해야합니다. 하지만 여전히 ID를 보여줄 사람은 한 명뿐입니다.
문제는 오래되었고 기술은 발전했습니다. 현재 상태는 다음과 같습니다.
JWT (JSON Web Token)는 웹 응용 프로그램 환경에서 당사자간에 클레임을 전달하기위한 JSON 기반 공개 표준 (RFC 7519)입니다. 토큰은 컴팩트하고 URL에 안전하며 특히 웹 브라우저 싱글 사인온 (SSO) 컨텍스트에서 사용 가능하도록 설계되었습니다.
요즘 웹 API 리소스를 보호하기 위해 가장 선호되는 방법은 서명 된 토큰 (특정 사용자를 식별하기에 충분한 정보가 포함되어 있음)을 사용하여 웹 API 서버에서 사용자를 인증하는 것입니다. 모든 요청. 이것을 토큰 기반 인증 방식이라고합니다.
토큰 기반 인증은 다음과 같이 작동합니다.
사용자는 클라이언트에 이름과 비밀번호를 입력합니다 (클라이언트는 브라우저 또는 모바일 장치 등을 의미).
그런 다음 클라이언트는이 자격 증명 (예 : 사용자 이름 및 비밀번호)을 Authorization Server에 보냅니다.
그런 다음 Authorization Server는 클라이언트 자격 증명 (예 : 사용자 이름 및 비밀번호)을 인증 한 다음 액세스 토큰을 생성하고 반환합니다. 이 액세스 토큰에는 사용자를 식별하기에 충분한 정보가 있으며 토큰 만기 시간도 있습니다.
그런 다음 클라이언트 응용 프로그램은 토큰이 만료 될 때까지 리소스 서버에서 제한된 리소스에 액세스하기 위해 HTTP 요청의 Authorization 헤더에 액세스 토큰을 포함시킵니다.
다음 기사는 WEB API에서 토큰 기반 인증을 단계별로 구현하는 방법을 보여줍니다.
https://dotnettutorials.net/lesson/token-based-authentication-web-api/
새 웹 사이트에 등록 할 때 종종 계정을 활성화하기 위해 이메일이 전송됩니다. 해당 이메일에는 일반적으로 클릭 할 수있는 링크가 포함되어 있습니다. 해당 링크의 일부, 토큰이 포함되어 있으며 서버는이 토큰에 대해 알고 귀하의 계정과 연결할 수 있습니다. 토큰에는 일반적으로 만료 날짜가 있으므로 링크를 클릭하고 계정을 활성화하는 데 1 시간 밖에 걸리지 않습니다. 고객이 이메일을 확인하는 데 사용하는 장치 또는 브라우저를 알 수 없으므로 쿠키 또는 세션 변수로는 불가능합니다.