Feathers: 새로 고침 토큰에 대한 지원 추가

:+1: @corymsmith 와 나는 이것에 대해 이야기하고 있었습니다. "휴가"를 통해 결승선을 넘어 이것을 걷어차도록 돕기를 바랍니다.

마스터에서 지원하지만 decoupling 브랜치에서도 지원합니다. 토큰을 새로 고치려면 두 가지 옵션이 있습니다.

1. 이메일/비밀번호, 트위터 등을 사용하여 재인증할 수 있습니다.
2. 유효한 토큰을 GET /auth/token/refresh 전달할 수 있습니다.

토큰 갱신 프로세스가 있지만 위에 게시한 Auth0 링크에 설명된 것처럼 완전한 갱신 토큰 지원은 아닙니다. 실제 새로 고침 토큰은 GitHub 인증 코드/비밀번호와 유사하게 작동하지만 새 JWT 토큰을 얻는 데만 사용할 수 있습니다. 따라서 JWT 토큰이 만료되더라도 새로 고침 토큰이 있으면 이를 사용하여 다시 로그인할 수 있습니다. userId가 그대로 유지되고 언제든지 취소될 수 있습니다. 적어도 그것이 내가 Auth0 기사에서 수집하고 있는 것입니다.

아 맞다 @marshallswain. 링크를 클릭했어야 한다고 생각합니다 :wink:

나는 첫 번째 컷을 위해 이것을 1.0 이정표에서 남겨 둘 것이라고 생각합니다. 사람들이 다시 인증하는 것은 쉽습니다.

저는 이것을 feathers-authentication 2.0으로 만드는 것에 투표합니다.

좋은 마음.

인증 워크플로가 정확히 어떻게 작동하는지 명확하지 않기 때문에 여전히 혼란스럽습니다.

지금 하고 있는 일은.
1.) 클라이언트가 사용자 이름 및 암호를 보냅니다.

 curl -X POST https://xxx/auth/local   -H "Content-Type: application/json"   -d '{ "email":"xxx", "password":"yyy"}'

이것은 JWT 토큰을 반환합니다.

{"token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJfaWQiOiI1NzhhNjUyN2RkMTZiMjIwMDRhY2ZjNmEiLCJpYXQiOjE0NzAzMjYyODUsImV4cCI6MTQ3MDQxMjY4NSwiaXNzIjoiZmVhdGhlcnMifQ.OVvQbnxfoDGxPFm3Y6tBhRae2Qa6_mDq-PVIo8RcC8Y"}

2.) 그런 다음 이 토큰을 Authorizatin http 헤더에 넣어 API에 액세스합니다.

curl -X GET https://xxx/users  -H 'Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJfaWQiOiI1NzhhNjUyN2RkMTZiMjIwMDRhY2ZjNmEiLCJpYXQiOjE0NzAzMjU1NzYsImV4cCI6MTQ3MDQxMTk3NiwiaXNzIjoiZmVhdGhlcnMifQ._CHdx3RpEuI189t90mXq-IMPXRNuoVh7nBwY1ON7xCY'

내가 이해하지 못하는 것은 이 토큰을 실제로 새로 고치는 방법입니다.
내가 시도한 것은 이 토큰을 xxx/auth/token/refresh로 보내는 것입니다.
내가 얻은 것은 또 다른 매우 긴 토큰입니다. 그런 다음 이전 토큰과 새 토큰을 모두 사용하여 API에 액세스하려고 했습니다. 둘 다 작동합니다 ... (이전 것을 비활성화해야하지 않습니까?)

curl -X GET https://xxx/auth/token/refresh  -H 'Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJfaWQiOiI1NzhhNjUyN2RkMTZiMjIwMDRhY2ZjNmEiLCJpYXQiOjE0NzAzMjU1NzYsImV4cCI6MTQ3MDQxMTk3NiwiaXNzIjoiZmVhdGhlcnMifQ._CHdx3RpEuI189t90mXq-IMPXRNuoVh7nBwY1ON7xCY'
{"query":{"token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJfaWQiOiI1NzhhNjUyN2RkMTZiMjIwMDRhY2ZjNmEiLCJpYXQiOjE0NzAzMjU1NzYsImV4cCI6MTQ3MDQxMTk3NiwiaXNzIjoiZmVhdGhlcnMifQ._CHdx3RpEuI189t90mXq-IMPXRNuoVh7nBwY1ON7xCY"},"provider":"rest","token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJxdWVyeSI6eyJ0b2tlbiI6ImV5SjBlWEFpT2lKS1YxUWlMQ0poYkdjaU9pSklVekkxTmlKOS5leUpmYVdRaU9pSTFOemhoTmpVeU4yUmtNVFppTWpJd01EUmhZMlpqTm1FaUxDSnBZWFFpT2pFME56QXpNalUxTnpZc0ltVjRjQ0k2TVRRM01EUXhNVGszTml3aWFYTnpJam9pWm1WaGRHaGxjbk1pZlEuX0NIZHgzUnBFdUkxODl0OTBtWHEtSU1QWFJOdW9WaDduQndZMU9ON3hDWSJ9LCJwcm92aWRlciI6InJlc3QiLCJ0b2tlbiI6ImV5SjBlWEFpT2lKS1YxUWlMQ0poYkdjaU9pSklVekkxTmlKOS5leUpmYVdRaU9pSTFOemhoTmpVeU4yUmtNVFppTWpJd01EUmhZMlpqTm1FaUxDSnBZWFFpT2pFME56QXpNalUxTnpZc0ltVjRjQ0k2TVRRM01EUXhNVGszTml3aWFYTnpJam9pWm1WaGRHaGxjbk1pZlEuX0NIZHgzUnBFdUkxODl0OTBtWHEtSU1QWFJOdW9WaDduQndZMU9ON3hDWSIsImRhdGEiOnsiX2lkIjoiNTc4YTY1MjdkZDE2YjIyMDA0YWNmYzZhIiwiaWF0IjoxNDcwMzI1NTc2LCJleHAiOjE0NzA0MTE5NzYsImlzcyI6ImZlYXRoZXJzIiwidG9rZW4iOiJleUowZVhBaU9pSktWMVFpTENKaGJHY2lPaUpJVXpJMU5pSjkuZXlKZmFXUWlPaUkxTnpoaE5qVXlOMlJrTVRaaU1qSXdNRFJoWTJaak5tRWlMQ0pwWVhRaU9qRTBOekF6TWpVMU56WXNJbVY0Y0NJNk1UUTNNRFF4TVRrM05pd2lhWE56SWpvaVptVmhkR2hsY25NaWZRLl9DSGR4M1JwRXVJMTg5dDkwbVhxLUlNUFhSTnVvVmg3bkJ3WTFPTjd4Q1kifSwiaWF0IjoxNDcwMzI2NDQyLCJleHAiOjE0NzA0MTI4NDIsImlzcyI6ImZlYXRoZXJzIn0.TqUv3051TTGbX4cPfkN-6pOOB5SN9nH-E7TU1HHSsb8","data":{"_id":"578a6527dd16b22004acfc6a","iat":1470325576,"exp":1470411976,"iss":"feathers","token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJfaWQiOiI1NzhhNjUyN2RkMTZiMjIwMDRhY2ZjNmEiLCJpYXQiOjE0NzAzMjU1NzYsImV4cCI6MTQ3MDQxMTk3NiwiaXNzIjoiZmVhdGhlcnMifQ._CHdx3RpEuI189t90mXq-IMPXRNuoVh7nBwY1ON7xCY"}}

더 이상한 점은 이 새 토큰을 사용하여 /auth/token/refresh로 다시 보내려고 했습니다.
나는 이것보다 더 긴 토큰을 얻었다.

여기서 내가 무엇을 잘못했거나 오해했는지 잘 모르겠습니다. 제안하십시오.

@parnurzeal 우리는 아직 새로 고침 토큰을 지원하지 않습니다. 이것이 제안된 기능인 이유입니다.

새 토큰을 얻는 방법은 기존의 유효한 JWT로 /auth/token 대한 POST를 수행하거나 다른 인증 메커니즘을 사용하여 로그인하는 것입니다. 당신은 모든 것을 올바르게하고있는 것 같습니다.

그렇긴 한데 제가 어떻게 했는지, 어떤 결과를 얻었는지 잘 봐주세요.

쉬운 예를 들어보겠습니다.
abcdefghijklmno 사용하여 새 토큰을 요청할 때(단지 임의의 말도 안되는 토큰).
응답 백은 이전 토큰의 더 긴 버전일 뿐입니다. -> abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz 사용하여 다시 시도하면 더 긴 버전을 얻게 됩니다 ->
abcdefghijklmnopqrstuvwxyz1234567890 및 루프가 계속됩니다(더 많이 요청하면 이전 버전의 더 긴 버전을 얻음).

또한 위의 세 가지 토큰을 모두 동시에 사용할 수 있습니다.
새 토큰을 요청한 후 이전 토큰이 만료되어야 하지 않습니까?

@parnurzeal 내 말은 그 기능이 실제로 구현되지 않았기 때문에 당신이 한 일을 하지 말라는 것입니다. 구현(지금까지)에 따르면 /auth/token/refresh 도달할 때마다 토큰이 계속 증가한다는 사실은 데이터를 토큰에 다시 밀어넣기 때문입니다. 이것은 작동하도록 의도된 방식이 아니며 완료할 시간이 없었으며 이것이 문서화되지 않은 이유입니다. 당신은 그것을 사용해서는 안됩니다.

새 토큰을 요청한 후 이전 토큰이 만료되어야 하지 않습니까?

이것이 JWT의 특성입니다. TTL에서 자체적으로 만료됩니다. 아직 만료되지 않은 오래된 토큰이 사용되는 것을 방지하려면 블랙리스트를 유지해야 합니다. 현재 이것은 여러분에게 달려 있으며 이에 대한 미해결 문제(#133)가 있지만 곧 (만약 있다면) 해결되지 않을 것입니다.

안녕하세요, 저는 /auth/refresh/token을 조사했고 다음과 같은 결과를 얻었습니다.

...
function pick (o, ...props) {
  return Object.assign({}, ...props.map(prop => ({[prop]: o[prop]})));
}

// Provider specific config
const defaults = {
  payload: ['id', 'role'],
  passwordField: 'password',
  issuer: 'feathers',
  algorithm: 'HS256',
  expiresIn: '1d', // 1 day
};
...
// GET /auth/token/refresh
  get (id, params) {
    if (id !== 'refresh') {
      return Promise.reject(new errors.NotFound());
    }

    const options = this.options;

    // Add payload fields
    const data = pick(params.payload, options.payload);

    return new Promise(resolve => {
      jwt.sign(data, config.get('auth').token.secret, options, token => {
        return resolve({token: token});
      });
    });

  }

구현이 너무 순진한가요? 그렇지 않은 경우 연마를 시도하고 몇 가지 테스트를 추가하고 PR을 만들 수 있습니다.

@aboutlo 노력에 감사드립니다! v0.8이 출시될 때까지 기다리는 것이 가장 좋습니다(지금은 알파 상태임). 많은 변경 사항이 있고 이번 주에 해당 경로가 사라질 수 있기 때문입니다.
저는 오늘 베타 릴리스를 중단하고 현재 마이그레이션 가이드를 마무리하고 있습니다. 따라서 길지 않을 것이며 v0.8은 인증과 관련된 많은 현재 문제를 해결합니다.

우리는 토큰을 새로 고침하기 위해 많은 생각을 했기 때문에 0.8이 출시되면(이번 주) 이 문제에 대해 논의하고 싶습니다. 이번 주 후반에 예비적인 생각을 하게 될 것입니다.

충분히 공정한 @ekryski , 나는 0.8을 기다릴 것입니다 :)

이 기능은 React Native 앱과 관련하여 MUST입니다. 사용자는 처음에 로그인하고 몇 주 후에 앱을 열면 여전히 로그인되어 있을 것으로 예상합니다.

@deiucanta 좋은 소식은 [email protected] 을 설계하는 동안 이 기능을 염두에

좋은 소식입니다! 👍 기대됩니다

@marshallswain 이 기능에 대한 업데이트를 기대합니다. 언제 예상되는지 알려주세요. 아니면 이미 출시된건가요? 미리 감사드립니다.

@deiucanta 그동안 이 기능이 출시될 때까지 수명이 더 긴 토큰을 사용할 수 있습니다. 해제되면 인증 암호를 새 값으로 교체하여 기존 세션을 모두 지우고 모든 사용자가 더 짧은 갱신 세션을 사용하도록 할 수 있습니다.

@atulrpandey 정식 출시는 아니지만 구현하기도 어렵지 않습니다. 새 새로 고침 토큰을 생성하고 DB의 사용자 개체에 저장하는 후크를 추가하기만 하면 사용되거나 만료되면 사용자에게서 제거합니다.

@pettermikitsh 당신이 할 수있는 또 다른 일은 (모바일에있는 경우) clientId 및 clientSecret 클라이언트에 안전하게 저장하고 JWT accessToken이 만료되면 다시 인증하십시오.

@ekryski 이러한 전략 중 하나의 예를 제공할 수 있습니까? 정말 도움이 될 것입니다.
아니면 공식 지원이 풀리는 데 시간이 오래 걸리나요? 이것은 모바일 인증에 정말 도움이 될 것입니다!

새로 고침 토큰 주제:

새로 고침 토큰은 새 액세스 토큰을 얻는 데 필요한 정보를 전달합니다. 즉, 특정 리소스에 액세스하기 위해 액세스 토큰이 필요할 때마다 클라이언트는 인증 서버에서 발급한 새 액세스 토큰을 얻기 위해 새로 고침 토큰을 사용할 수 있습니다. 일반적인 사용 사례에는 이전 액세스 토큰이 만료된 후 새 액세스 토큰을 얻거나 새 리소스에 처음으로 액세스하는 것이 포함됩니다. 새로 고침 토큰도 만료될 수 있지만 오히려 오래 지속됩니다. 새로 고침 토큰은 일반적으로 유출되지 않도록 엄격한 저장 요구 사항이 적용됩니다. 인증 서버에서 블랙리스트 에 https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/

그래서 생각보다 빨리 React Native에 입문했습니다. 나는 이것을 기여할 수 있을지 생각하고 있지만 그것이 올바른 구현인지 확인하기 위해 메커니즘을 완전히 이해하고 있는지 확인하고 싶습니다. 새로 고침 토큰은 상태 비저장이 아니므로 사용에 몇 가지 제약이 있습니다(예: 개발자가 저장소 어댑터를 제공해야 함).

유효한 JWT를 사용하여 새로 고침 토큰을 얻을 수 있습니까? 아니면 인증 응답에서 새로 고침 토큰이 자동으로 반환됩니까(예: accessToken )? Auth0이 https://auth0.com/learn/refresh-tokens/ 의 예에서 인증 응답( accessToken 및 refreshToken )에 이를 포함하는 것 같습니다 .

@pettermikitsh 유효한 JWT를 사용하여 새로 고침 토큰을 얻을 수 있어야 한다고 생각하지 않습니다. 그렇게 하면 누구나 JWT를 얻을 수 있고 계정에 계속 액세스할 수 있습니다.

새로 고침 토큰은 일반적으로 로그인/가입 응답과 함께 반환되며 클라이언트는 다시 로그인/가입하여 새 세션과 새 새로 고침 토큰을 제공하지 않는 한 특정 세션에 대해 다시 액세스할 수 없습니다.

새로 고침 토큰은 실제로 만료될 필요가 없지만 데이터베이스에 저장되는 경우 호출될 수 있으므로 사용자는 이러한 방식으로 얼마나 많은 활성 세션이 있는지 확인할 수 있습니다. 새로 고침 토큰을 발행할 때 더 많은 정보를 저장할 수 있습니다(예: os, ip, 장치 이름 등).

적어도 저는 그렇게 합니다.

새로 고침 토큰을 발급할 때와 새로 고침 토큰을 사용하려고 할 때 인증을 확인하는 한 유효한 JWT를 사용하여 새로 고침 토큰을 가져오는 것이 좋습니다.

@marshallswain

현재 유효한 인증 토큰을 <loginEndpoint>/refresh 에 게시하여 새 토큰을 받을 수 있습니다. 새로 고침 토큰에는 약간 다른 워크플로가 있습니다...

따라서 혼동을 피하기 위해 refresh 가 아닌 renew 불러야 합니다. <loginEndpoint>/renew

@abhishekbhardwaj가 말했듯이

accessToken은 accessToken으로 새로 고칠 수 없고 refresehToken 또는 사용자 이름/비밀번호로만 새로 고칠 수 있어야 합니다. 인증...

현재 다음과 같이 accessToken을 사용하여 accessToken을 새로 고칠 수 있습니다.

https://github.com/feathersjs/authentication-jwt/issues/61

또 다른 접근 방식은 accessToken의 페이로드 내부에 새로 고침 토큰을 저장한 다음 현재 새로 고침 API가 새로 고침 토큰이 취소되지 않았는지 확인하는 것입니다(데이터베이스 또는 redis 호출을 통해). 이 방법으로 새로 고침 토큰은 간단한 자동 증가 ID가 될 수 있습니다. 또한 새로 고침 API는 더 이상 만료를 확인하지 않아야 합니다. 갱신 토큰(단순 정수)은 액세스 토큰으로 서명되어 있으므로 안전합니다.

이 방법은 현재 코드 기반에 대한 변경을 최소화해야 합니다. 새로 고침 API의 경우 사용자가 액세스 토큰이 취소되지 않았는지 확인하는 방법을 제공합니다(페이로드 내부의 새로 고침 토큰 확인을 통해). 이 후크가 제공되면 t 더 이상 만료 시간을 확인합니다.

@arash16에서 이 접근 방식을 좀 더 설명해

accessTokens 페이로드에 새로 고침 토큰을 저장하고 새로 고침 API가 만료를 확인하지 않으면 모든 accessToken을 "비만기"로 효과적으로 만들지 않았습니까?

모든 accessToken을 사용하여 새 액세스 토큰을 얻을 수 있기 때문입니다. 맞습니까?

내가 뭔가를 놓치고 있습니까?

@BigAB
나는 refresh api 에 대해서만 만료를 확인하지 않는다는 것을 의미했습니다. 동일한 accessToken이 refresh-token과 access-token으로 모두 사용됩니다. 이 토큰은 새로고침하고 새 액세스 토큰을 얻는 경우에만 만료되지 않으며, 사용자가 수동으로 refresh-id 자체를

개발자는 모든 새로 고침 ID를 저장할 db-table/redis가 있어야 합니다. 사용자가 일부(또는 모든) 다른 세션에서 취소하거나 로그아웃해야 하는 경우 모든 새로 고침 ID 목록(브라우저 또는 생성 날짜 등과 같은 기타 추가 정보 포함)을 제공할 수 있으며 사용자는 제거(서명 - 밖으로) 선택적으로. 그런 다음 해당 새로 고침 ID를 포함하는 실제 토큰이 만료되면 새로 고침 API가 새 토큰 제공을 거부합니다.

토큰 내부의 refresh-id는 대부분 사용되지 않으며 토큰이 만료될 때까지 권한 부여가 상태 비저장입니다.

액세스 토큰의 만료 시간은 짧을 수 있으며(10분 미만) 사용자는 페이지를 닫고 자리를 뜰 수 있으며 나중에 페이지를 열면 액세스 토큰이 이미 만료되어 로그아웃됩니다. 그러나 토큰 내부의 refresh-id는 데이터베이스에서 관리하는 수명 이 훨씬

보안 관점에서 이 방식으로 사용되는 액세스 토큰은 이전 세션 키처럼 취급되어야 하며, 매번(만료된 한 번만) 유효성을 검사하기 위해 데이터베이스를 호출할 필요가 없다는 추가 이점이 있습니다.

@ arash16 , 액세스 JWT 내부에 새로 고침 토큰을 저장하는 아이디어가 좋습니다. 서버 측에서 이 새로 고침 토큰을 검색하는 방법에 대한 예가 있습니까?

내 현재 문제: 액세스 토큰이 만료되면 페더의 후크 컨텍스트에서 페이로드를 사용할 수 없습니다. @feathersjs/authentication 패키지의 verifyJWT() 유틸리티 기능을 사용하는 방법이 있다고 생각합니다. 예를 들어 app.service('authentication').hooks({ before: { create: ... } }) 의 맨 처음에 ?

지금 깃털에 새로 고침 토큰을 사용하는 주의깊은 방법이 있습니까? 그들에 대한 지원을 추가할 계획이 있습니까?

모두들 안녕 ,

아직 사용할 수 없는 것 같습니다(또는 내가 놓치고 있는 것이 있습니까). 언제 사용할 수 있는지 알려주시겠습니까? 사용 가능한 여권 갱신 토큰 저장소가 있습니다. 아무도 이것을 시도 했습니까?
https://github.com/fiznool/passport-oauth2-refresh

안녕하세요 @daffl님
Google 전략을 위해 토큰을 새로 고칠 수 있는 방법을 이해하는 데 도움을 줄 수 있는 사람이 있습니까? Google 로그인 시나리오에 대한 비밀번호가 없기 때문에?

감사 해요

또 다른 접근 방식은 accessToken의 페이로드 내부에 새로 고침 토큰을 저장하는 것입니다.

따라서 만료된 액세스 토큰 중 하나 라도 가지고 있는 사람은 누구나 쉽게 새로운 액세스 토큰을 끝없이 생성할 수 있습니다. 아니면 제가 놓친 것이 있습니까?

새로 고침 토큰은 클라이언트에 안전하게 저장되어야 하며 이 클라이언트를 제외한 누구도 토큰에 액세스할 수 없어야 합니다!

@deiucanta 좋은 소식은 [email protected] 을 설계하는 동안 이 기능을 염두에

이것은 2016년에 게시되었습니다. 여러분, 이 필수 기능을 아직 지원할 계획이 있습니까?

아니요. 만료된 토큰으로는 아무 것도 할 수 없습니다. 또한 갱신 토큰은 v4 시험판 에서 훨씬 더 쉽게 가능합니다. 그것을 하는 방법에 대한 요리책 항목은 최종 릴리스의 일부가 될 것입니다.

또한 갱신 토큰은 v4 시험판 에서 훨씬 더 쉽게 가능합니다.

대략적인 출시일이 있습니까?

그것을 하는 방법에 대한 요리책 항목은 최종 릴리스의 일부가 될 것입니다.

이 가이드가 출시될 때까지 v4 프리릴리즈에서 수행할 수 있는 방법을 몇 마디로 설명해 주시겠습니까?

@대플핑

아직 공식적인 방법이 없나요? v4가 여기에 있으며 문서에 아무 것도 표시되지 않습니다.

@daffl 인증 서비스에 대한 해킹 없이 4.0에서 이것이 어떻게 달성될 수 있는지 자세히 설명해 주시겠습니까?

@MichaelErmer 를 해결 방법으로 로컬 또는 사용자 정의 전략을 사용하여 jwt를 갱신할 수 있지만 이상적이지는 않지만 내부 통신에는 잘 작동합니다.

function initAuth() {
  return async (ctx) => {
    if (ctx.path !== 'authentication') {
      const [authenticated, accessToken] = await Promise.all([
        ctx.app.get('authentication'),
        ctx.app.authentication.getAccessToken(),
      ]);

      if (!accessToken || !authenticated) {
        const result = await ctx.app.authenticate(apiLocalCreds);
        ctx.params = {
          ...ctx.params,
          ...result,
          headers: { ...(ctx.params.headers || {}), Authorization: result.accessToken },
        };
      } else {
        const { exp } = decode(accessToken);
        const expired = Date.now() / 1000 > exp - 60 * 60;
        if (expired) {
          const result = await ctx.app.authenticate(apiLocalCreds);
          ctx.params = {
            ...ctx.params,
            ...result,
            headers: { ...(ctx.params.headers || {}), Authorization: result.accessToken },
          };
        }
      }
    }
    return ctx;
  };
}

client
  .configure(rest(apiHost).superagent(superagent))
  .configure(auth(authConfig))
  .hooks({ before: [initAuth()] });

현재 저는 v4 authentication 에서 이 after 후크를 사용하여 20일 후에 내 accessToken을 업데이트하고 있습니다...

````자바스크립트
const {날짜 시간} = 요구('luxon')
const 갱신 후 = {일: 20}

module.exports = () => {
비동기 컨텍스트 반환 => {
만약 (
context.method === '만들기' &&
context.type === '뒤에' &&
context.path === '인증' &&
context.data && context.data.strategy === 'jwt' &&
context.result &&
context.result.accessToken) {
// 토큰 갱신이 필요한지 확인
const 페이로드 = context.app.service('인증').verifyAccessToken(context.result.accessToken)을 기다립니다.
const 발행 시간 = DateTime.fromMillis(payload.iat * 1000)
const 갱신후 = 발행된At.plus(갱신후)
지금 const = DateTime.local()
if (지금 > 갱신후) {
context.result.accessToken = 대기 context.app.service('인증').createAccessToken({sub: payload.sub})
}
}
컨텍스트 반환
}
}
````

이 후크를 after 및 마지막 후크로 두어 모든 확인 등이 통과되도록 하는 것이 중요합니다.

깃털에 새로 고침 토큰을 통합할 계획이 있습니까?

나는 그 질문을 한 메시지 더 일찍 두 번째로 한다.

새로 고침 토큰 워크플로에 대해서도 궁금합니다. @m0dch3n 이 작성한 솔루션이 좋은 방법입니까? 다른 방법으로 구현해야 합니까?

내 의견의 전체 refreshToken 워크플로는 중간 공격자에 대해 약간만 보호하므로 중간 사람이 accessToken을 훔친다면 최소한 새로 고침할 수 없고 리소스에 무한한 액세스 권한을 가질 수 있습니다.

XSS로부터 보호하지 않습니다. 이 경우 공격자가 클라이언트 측에 저장된 모든 것을 훔칠 수 있기 때문입니다. 리프레시토큰도 그렇고...

이제 문제는 accessToken 만료 시간을 너무 짧게(즉, 5분) 만들면 너무 자주 새로 고침을 해야 한다는 것입니다. 중간에 있는 남자는 refreshToken을 가로채기 위해 클라이언트 요청을 5분 동안만 들어야 합니다. 그러면... 만료를 더 길게 만들면 accessToken만으로도 더 오래 액세스할 수 있습니다...

솔직히 일부 클라이언트가 액세스 권한을 도난당했다고 말하면 accessToken 과 refreshToken을 블랙리스트에 추가해야 확실하게 알 수 있습니다. 그래서 어쨌든 각 요청에 대해 DB 요청을해야합니다.

제 경우에는 그러한 경우를 알고 있을 때 지난 40일 동안의 모든 accessTokens를 블랙리스트에 올렸습니다. 왜냐하면 제 accessTokens의 유효 기간이 40일이기 때문입니다...

HTTPS 요청을 사용하면 중간자 공격이 정말 어려워집니다. HTTPS 요청을 사용하고 있지 않습니까?

물론 저는 https를 사용하고 있지만 accessToken을 훔칠 가능성은 3가지가 있습니다. 첫 번째는 클라이언트 측(예: XSS), 두 번째는 전송(가운데 사람), 세 번째는 서버 측입니다.

클라이언트와 전송에서 나는 보안에 대한 절반만 책임지고 나머지 절반은 내 통제 하에 있지 않은 클라이언트입니다. 하지만 XSS를 불가능하게 만들고 https로 전송을 보호함으로써 클라이언트가 보안 위험을 피하도록 도울 수 있습니다.

refreshToken의 목표는 accessToken의 만료를 더 짧게 만들고 각 요청에 대해 더 길거나 무한한 유효한 토큰을 전송하지 않는 것입니다.

따라서 이것이 제공하는 유일한 보안은 100개의 요청에서 즉, 전송 시 100개 모두를 취약하게 만드는 것이 아니라 1개의 요청만 한다는 것입니다.

따라서 기본적으로 중간 공격자는 refeshToken에 의해 보호될 수 없으며 물론 XSS에 의해 보호되지 않습니다... 이 refreshToken을 전송하는 횟수만큼 줄일 수 있을 뿐입니다... 전송 비용은 더 적습니다. 그러나 accessToken은 더 오래 유효해야 합니다...

Slack 채널에서 내 댓글을 복사/붙여넣기만 하면 됩니다.

새로고침 토큰은 필수 지원 기능이며 기존 액세스 토큰을 자동으로 갱신하는 것이 아닙니다. 액세스 토큰은 상태 비저장이며 서버 측에 저장되지 않습니다. 단점은 영원히 유효하다는 것입니다! 액세스 토큰이 길수록 더 많은 위험이 부과됩니다. 그러나 액세스 토큰이 너무 짧으면 사용자가 자주 로그인해야 하므로 사용성에 큰 영향을 미칩니다.

리프레시 토큰이 들어오는 곳입니다. 액세스 토큰을 새로 고치는 데 사용되는 토큰이며 수명이 긴 토큰입니다. 액세스 토큰이 만료되면 클라이언트는 새로 고침 토큰을 사용하여 새 액세스 토큰을 얻을 수 있으며 이것이 새로 고침 토큰의 유일한 목적입니다.

사용자 계정이 도용된 경우 새로 고침 토큰을 취소할 수 있습니다. 그리고 이것이 액세스 토큰과 새로 고침 토큰의 큰 차이점입니다. 발급된 리프레시 토큰을 취소하려면 서버에서 발급된 모든 리프레시 토큰을 저장해야 합니다. 즉, 새로 고침 토큰은 상태를 저장합니다. 서버는 어떤 것이 유효한지, 어떤 것이 유효하지 않은지 알아야 합니다.

새로 고침 토큰을 올바르게 구현하려면 새로 고침 토큰을 유지하기 위한 일종의 토큰 저장소가 필요합니다. 또한 최소한 세 가지 흐름을 구현해야 합니다.

토큰 유효성 검사 새로 고침
유효한 새로 고침 토큰으로 액세스 토큰 새로 고침
손상된 사용자의 새로 고침 토큰 취소

토큰 사용 통계와 같은 다른 관리 기능도 있으면 좋습니다.

위는 새로 고침 토큰을 구현하는 방법에 대한 현재 이해입니다. 쉽지는 않지만 보다 안전한 시스템을 구축하는 것은 반드시 필요합니다.

새로 고침 토큰을 올바르게 구현하는 데 필요한 모든 기능/모듈이 Feathers에 이미 내장되어 있는 것으로 나타났습니다.

1. Refresh-token store: Feathers Service에서 쉽게 지원받을 수 있습니다.
2. 새로 고침 토큰 발급 및 검증: 내장된 AuthenticationService가 지원하는 기존 JWT를 재사용할 수 있습니다.

TheSinding(https://github.com/TheSinding/authentication-refresh-token)이 수행한 작업을 기반으로, 하나의 사용자 지정 서비스와 세 개의 후크(https://github.com/ 기본 새로 고침 토큰 기능을 활성화하는 jackywxd/feathers-refresh-token):

1. 사용자 인증에 성공한 후 새로 고침 토큰을 발행하십시오.
2. 유효한 JWT 새로 고침 토큰으로 액세스 토큰을 새로 고칩니다.
3. 새로 고침 토큰을 삭제하여 사용자 로그아웃

Feathres의 기존 코드 기반을 최대한 활용하면서 실제 코딩 노력은 최소화되었으며 현재 Feathers 아키텍처와 잘 통합됩니다. 현재 Feathers 아키텍처가 매우 확장 가능하다는 것을 증명합니다.

그러나 Refresh-token의 전체 기능은 클라이언트 측에서 새로 고침 토큰 저장, 액세스 토큰 만료 후 사용자 재인증, 새로 고침 토큰으로 사용자 로그아웃과 같은 클라이언트 측 지원도 필요합니다.

feather-authentication 및 authentication-client의 소스 코드를 검토한 후 새로 고침 토큰을 인증을 켜는 것만큼 쉽게 새로 고침 토큰 지원을 켤 수 있도록 기반으로 하는 기존 기능 코드에 탭핑할 수 있다고 생각합니다.

내 후크 버전 새로 고침 토큰 코드 기반을 @feathersjs/authentication으로 이미 이식했습니다. 다음으로 클라이언트 측 기능을 활성화하기 위해 인증 클라이언트를 변경하려고 합니다. 제 궁극적인 목표는 서버 측과 클라이언트 측 모두에서 새로 고침 토큰 지원을 활성화하는 것입니다.

내 질문/관심은 새로 고침 토큰이 클라이언트에 어떻게 저장됩니까?

https://auth0.com/blog/securing-single-page-applications-with-refresh-token-rotation/ 참조

불행히도 수명이 긴 RT는 SPA에 적합하지 않습니다. 브라우저에는 의도한 애플리케이션에서만 액세스를 보장할 수 있는 영구 저장 메커니즘이 없기 때문입니다. 이러한 고가치 아티팩트를 획득하고 악의적인 행위자가 보호된 리소스에 대한 액세스 권한을 부여하기 위해 악용될 수 있는 취약점이 있으므로 SPA에서 새로 고침 토큰을 사용하는 것은 강력히 권장되지 않습니다.

https://afteracademy.com/blog/implement-json-web-token-jwt-authentication-using-access-token-and-refresh-token 참조

그렇다면 토큰을 안전하게 보관할 수 있는 가장 좋은 장소는 어디일까요? 완전히 안전한 스토리지를 확보하려는 열정이 있다면 인터넷에서 이에 대한 자세한 내용을 읽을 수 있습니다. 일부 솔루션은 이상적이지만 그다지 실용적이지 않습니다. 실제로 httpOnly 및 Secure 플래그가 있는 쿠키에 저장합니다. 100% 안전하지는 않지만 작업을 완료합니다.

쿠키에 대한 이 긴 토론을 참조하십시오 - https://github.com/feathersjs-ecosystem/authentication/issues/132 too

@bwgjoseph 일반 익스프레스 세션을 사용하고 클라이언트 측 대신 모든 토큰을 거기에 저장하는 것이 좋습니다. 그것이 내가하는 일이며 SPA를 포함한 모든 유형의 앱에서 완벽하게 작동합니다.

@sarkistlt 모든 클라이언트 JWT 토큰을 서버 측에 저장한다는

@bwgjoseph 언제나처럼 쿠키, 서비스를 등록하기 전에

app.use('* | [or specific rout]', session(sess), (req, res, next) => {
      req.feathers.session = req.session || {};
      next();
    });

그런 다음 서버에서 고객 로그인 서비스의 경우 고객이 인증되면 ctx.params.session.token = token 와 같은 세션에 토큰을 저장하면 됩니다. 여기서 토큰은 JWT 액세스 또는 새로 고침 토큰이며 애플리케이션 논리에 따라 다릅니다.
그리고 클라이언트의 새로운 요청이 있으면 세션에 토큰이 있는지 확인하고 이를 인증에 사용할 것입니다. 클라이언트 측에서 토큰이 전혀 노출되지 않기 때문에 이것은 훨씬 더 안전하고 안전한 접근 방식입니다.

나는 이것이 클라이언트(브라우저) - 서버 응용 프로그램에 가장 잘 작동한다고 덧붙이겠습니다. 서버 또는 작업자/서버 간에 내부적으로 통신할 때는 세션이 필요하지 않습니다.

이것은 이전에 _많이_ 논의되었으며(또한 FAQ에 항목을 추가했습니다) 세션에 토큰을 저장하는 것이 반드시 더 안전한 것은 아닙니다. 누군가가 스크립트를 실행할 수 있도록 페이지에 액세스하면 세션을 가로채고 어쨌든 인증된 요청을 할 수 있습니다.

따라서 일반적으로 토큰을 예를 들어 localStorage(현재 페이지에만 액세스할 수 있음)에 저장하는 것이 좋으며 브라우저가 아닌 다른 플랫폼(네이티브 모바일 앱, 서버 간 등)과도 원활하게 작동합니다. websockets__ (웹 소켓이 HTTP 쿠키로 원활하고 안전하게 작동하도록 하는 것이 얼마나 고통스러운지 충분히 강조할 수 없습니다. 우리가 그렇게 하려고 하지 않은 이후로 제 삶은 훨씬 쉬워졌습니다). 일반적으로 새로 고침 토큰은 수명이 훨씬 더 길기 때문에 취소할 수 있어야 합니다.

어느 쪽이든, 이것에 대한 풀 리퀘스트는 매우 환영받을 것입니다. 세부 사항을 훨씬 쉽게 다림질할 수 있습니다.

@jackywxd - 훌륭한 작업입니다. 간단히 살펴보았고 몇 가지 훌륭한 추가 기능이 있는 것 같습니다.
어쨌든 개발자가 이것을 구현하기 쉽게 만들 수 있습니까?
만든 후크를 라이브러리에 통합하는 것처럼 나중에 후크를 추가할 필요가 없습니까?

풀 리퀘스트를 생성하고 거기에서 토론을 할 수 있어야 한다고 생각합니다.

@daffl 예, 특히 WS에 동의합니다. 그리고 클라이언트와 백엔드가 모두 귀하 또는 귀하의 팀에 의해 구축되는 경우 JWT를 사용하고 애플리케이션의 추가 종속성과 복잡성을 피하는 것이 가장 좋습니다.
그러나 어떤 경우에는 예를 들어 타사 회사/개발자가 사용할 상점 앞 REST-API를 구축할 때 일반 세션을 사용하고 개발자에게 요청에 자격 증명을 포함하도록 요청한 다음 액세스(및 새로 고침) 방법을 설명하도록 요청하는 것이 더 쉽습니다. ) 토큰을 저장하고 각 요청과 함께 전달합니다. 페더 클라이언트에서 완벽하게 처리하지만 개발자가 백엔드 빌드 방법에 익숙하지 않은 대부분의 경우 request, superagent, fetch or axios 를 사용하여 애플리케이션을 백엔드에 연결합니다. 적어도 제 경우에는 이것이 JWT가 아닌 일반 세션에서 직접 작동하도록 API의 첫 화면 부분을 이동하는 주된 이유였습니다.

그러나 이 결정을 커뮤니티에 "강제"하는 대신 자체 API로 구현한 다음 이 기능을 적절하게 문서화하는 것이 디자인 결정과 책임이 해당 상점의 제작자에게 있지 않을까요?

@TheSinding 사용자 세션을 관리하기 위해 가장 일반적으로 사용되는 접근 방식인 쿠키가 아니라 덜 일반적으로 사용되는 접근 방식에 대해 '강제'라고 말할 수 있다고 생각합니다.

그리고 네, API를 사용해 온 개발자들의 피드백을 받아 디자인 결정을 한 것입니다. 여러 팀에서 사용하는 다중 테넌트 시스템 또는 API를 실행하는 경우, 특히 대체 솔루션이 최종 사용자에게 이점을 제공하지 않는 경우 개발자가 추가 혼란과 추가 시간을 소비하지 않도록 일반적인 업계 관행을 따르는 것이 가장 좋습니다.

다시 말하지만 JWT를 사용하는 것은 훌륭하고 특히 실시간 API에 활용하기가 훨씬 더 쉽습니다. 우리가 90%의 경우에 사용하고 있는 것입니다. + 쿠키 세션을 관리하기 위해 redis 또는 다른 것을 실행할 필요가 없습니다.
그러나 최선의 선택이 아닐 수 있는 예외적인 경우가 있으므로 이전 의견에서 해당 상황의 예를 가져왔습니다.

나는 당신이 틀렸다고 말한 것이 아니라 "큰 소리로"생각했습니다 :)

IMO, JWT를 사용한 접근 방식이 더 나은 접근 방식이라고 생각합니다. 이미 지원되고 @daffl 로 작업하기도 더 쉽기 때문입니다.

모든 피드백에 감사드립니다! JWT 대 세션은 별도로 논의할 수 있는 다른 주제입니다.

우리 모두가 동의하는 한 가지는 액세스 토큰 + 새로 고침 토큰이 단순한 액세스 토큰보다 훨씬 더 안전한 솔루션이라는 것입니다. 그것은 주요 인터넷 거인에 의해 널리 채택되었습니다. Feathers 커뮤니티는 새로 고침 토큰에 대한 기본 제공 지원을 제공하기 위해 Feathers 기본 코드 기반을 보고 싶어한다고 말하는 것이 타당합니다. 사실 Feathers가 새로 고침 토큰을 지원하지 않는다는 사실을 처음 알았을 때 놀랐습니다.

저는 몇 가지 프로젝트에서 AWS cognito를 사용하고 있습니다. AWS Amplify는 ID 토큰, 액세스 토큰 및 새로 고침 토큰과 같은 세 가지 토큰을 localStorage에 저장합니다. Amplify는 토큰 관리와 관련된 모든 더러운 작업을 처리하고 쉽고 간편하게 사용할 수 있는 몇 가지 API를 제공합니다. Cognito 백엔드와 함께 작동하는 직관적인 인터페이스. Feathers와 비슷한 개발 경험을 보고 싶습니다.

@Sinding 이전의 훌륭한 작업에 감사드립니다!

기존 인증은 일반 서비스로 구현되기 때문에 클래스를 확장하고 몇 개의 후크를 추가하여 새로 고침 토큰 지원을 쉽게 활성화할 수 있습니다.

this.hooks({ after: { create: [issueRefreshToken(), connection('login'), event('login')], remove: [logoutUser(), connection('logout'), event('logout')], patch: [refreshAccessToken()], },

CLI를 사용하여 인증을 켜는 것처럼 새로 고침 토큰 지원을 위해 CLI에서 유사한 옵션을 제공할 수 있습니다. 개발자는 간단히 예라고 대답하면 CLI가 자동으로 고객 "새로 고침 토큰" 서비스를 만들고 기본 구성 파일에서 새로 고침 토큰 관련 구성을 업데이트할 수 있습니다. 따라서 개발자를 위한 턴키 솔루션과 같습니다.

@daffl David, 깃털을 만들어 주셔서 감사합니다! Feathers에 대한 "기여 가이드", "코딩 가이드라인", "스타일 가이드"가 있는지 궁금합니다.

이전에 언급했듯이 새로 고침 토큰(또는 일부 아이디어)을 구현하는 PR은 매우 환영할 것입니다. 아직 링크된 저장소를 확인할 기회가 없었고 이 토론이 꽤 길어지고 있습니다. 모든 것을 한 곳에서 최신 상태로 유지하면 일이 훨씬 쉬워집니다. 몇 가지 중요한 글머리 기호:

• 인증 서비스 를
• 새로 고침 토큰은 localStorage에 저장해야 합니다.
• 새로 고침 토큰은 취소할 수 있어야 합니다(따라서 https://docs.feathersjs.com/cookbook/authentication/revoke-jwt.html에 설명된 취소 메커니즘의 보다 일반적인 목적 구현이 필요함)
• 추가 복잡성 및 설정(취소된 토큰 저장을 위한 Redis와 같은)으로 인해 기능으로 사용할 수 있지만 기본적으로 활성화되어서는 안 됩니다(즉, 표준 생성 앱 - CLI의 일부일 수 있지만 이에 대해 아무것도 하기 전에, 나는 여전히 hygen 기반 발전기를 시작하는 데 도움을 찾고 있습니다.)
• 기여 정보는 기여자 가이드 에서 찾을 수 있습니다.

누군가가 refreshToken을 사용하고 있다면 우리는 사용하기 너무 쉬운 "세션"과 같은 프론트엔드, accessToken 및 refreshToken을 처리하는 라이브러리를 만듭니다.

토큰을 전달하기만 하면 라이브러리는 만료될 때 refreshToken을 사용하여 새 acessToken을 얻으려고 시도합니다. 현재 Videsk 에서 사용됩니다.

저장소: 전면 인증 처리기