토큰 기반 인증에 대한 대체 접근 방식

Question

사용자가 웹/모바일 클라이언트 세트를 통해 액세스 할 수있는 RESTful API를 보유하고 있으며 토큰 인증을 처리하는 방법을 파악하려고합니다. 토큰은 모든 요청 만료시

, 새와 함께 전달,

1. 사용자에 한해 승인을 사용자가/통과 제공함으로써, 때까지 토큰 및 만료
2. 를 다시 수신 : 나의 이해는 기존의 토큰 인증은 다음과 같이 작동한다는 것입니다 토큰이 요청됩니다 (별도의 '새로 고침'토큰을 제공하거나 사용자/패스로 다시 인증함으로써)

각 요청마다 새 토큰을 생성하지 않는 것이 좋은 이유가 있습니까? 초기 토큰은 사용자/패스를 통해 요청됩니다. 이 토큰은 첫 번째 API 요청과 함께 전달됩니다.이 요청은 API 응답의 내용과 다음 요청과 함께 전달되어야하는 새 토큰을 반환합니다.이 접근법의 장점은 사용자가 요청한 각 요청 (동작) 토큰 만료 시간은 기본적으로 사용자가 로그 아웃하지 않고 비활성화 될 수있는 기간이되도록 토큰 auth의 만료를 재설정합니다. 이 접근법을 사용하지 않는 좋은 이유가 있습니까? 위에 제시된 접근법이 더 평범한 것처럼 보입니다 (그래서 내가 묻습니다).

마지막으로, 약간 만 관련된 질문입니다. 네트워크에서 사용자가 토큰을 가져 오는 것을 지켜 보는 누군가를 막을 수 있습니까? 특히 첫 번째 계획에서는 쉽게 할 수 있습니다 (두 번째 방법에서는 들어오는 요청을 캡처 한 다음 사용자가하기 전에 다음 토큰을 빠르게 가져와야합니다).

Answer 1

내가 읽은 것은 사용자가 인증 된 슬라이딩 창을 원한다는 것입니다. 만료 기간 내에 요청이있을 때마다 세션이 연장됩니다. 내가 올바르게 이해한다면 대체 방법을 제안 할 것입니다. 요청이 성공적으로 인증 될 때마다 토큰이있는 상점을 갱신하고 만기 시간을 갱신하십시오. 이렇게하면 매번 새 토큰을 잡는 번거 로움을 덜어 줄 필요가 없습니다. 그렇습니다. 그렇습니다. 그렇게하지 않는 것이 좋은 이유가 있습니다. 유스 케이스에는 필요하지 않으며 사용자 만 괴롭 히게됩니다.

위의 접근 방식을 사용하면 토큰과 만료일을 보관하는 저장소 (데이터베이스)가 있다고 가정합니다.

그래서 과정은 이것이다 :

1. 사용자는 사용자 이름 + 비밀번호
2. 이 저장소에
3. 가지 적어 사용자 토큰
4. 업데이트 저장소 성공적인 요청이
를 만든 때마다 기록을 작성 제공

관련 참고 사항; 사용자에게 만기 날짜를주지 마십시오. 예를 들어 쿠키를 사용할 때는 괜찮습니다.하지만 이는 단지 추가적인 보안 수단으로 유용합니다.

약간 관련 질문에; TLS/SSL/HTTPS를 사용하지 않으면 아무도 토큰을 가져 가지 못합니다. 항상 TLS (HTTPS 인 SSL)를 사용하십시오.