Should I refresh access token on API
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
There is a case when a specific authorized user changes his password or email. As email or password is part of user authentication, I think that it is necessary to revoke all auth tokens.
What is the best practice to refresh auth token in the case where a user has changed their password or email?
I do not use OAuth but have usual Bearer token in a header.
The idea is to store on the client side an additional refresh token, every time the mail or password changes, we do revoke his access token. After this user can make a request with refresh token to get new access token
rest api authentication
edited Nov 16 '18 at 18:21
GrayedFox
7641229
asked Nov 16 '18 at 13:12
coder firecoder fire
311416
add a comment |
There is a case when a specific authorized user changes his password or email. As email or password is part of user authentication, I think that it is necessary to revoke all auth tokens.
What is the best practice to refresh auth token in the case where a user has changed their password or email?
I do not use OAuth but have usual Bearer token in a header.
The idea is to store on the client side an additional refresh token, every time the mail or password changes, we do revoke his access token. After this user can make a request with refresh token to get new access token
rest api authentication
edited Nov 16 '18 at 18:21
GrayedFox
7641229
asked Nov 16 '18 at 13:12
coder firecoder fire
311416
add a comment |
There is a case when a specific authorized user changes his password or email. As email or password is part of user authentication, I think that it is necessary to revoke all auth tokens.
What is the best practice to refresh auth token in the case where a user has changed their password or email?
I do not use OAuth but have usual Bearer token in a header.
The idea is to store on the client side an additional refresh token, every time the mail or password changes, we do revoke his access token. After this user can make a request with refresh token to get new access token
rest api authentication
edited Nov 16 '18 at 18:21
GrayedFox
7641229
asked Nov 16 '18 at 13:12
coder firecoder fire
311416
There is a case when a specific authorized user changes his password or email. As email or password is part of user authentication, I think that it is necessary to revoke all auth tokens.
What is the best practice to refresh auth token in the case where a user has changed their password or email?
I do not use OAuth but have usual Bearer token in a header.
The idea is to store on the client side an additional refresh token, every time the mail or password changes, we do revoke his access token. After this user can make a request with refresh token to get new access token
rest api authentication
rest api authentication
edited Nov 16 '18 at 18:21
GrayedFox
7641229
asked Nov 16 '18 at 13:12
coder firecoder fire
311416
edited Nov 16 '18 at 18:21
GrayedFox
7641229
asked Nov 16 '18 at 13:12
coder firecoder fire
311416
edited Nov 16 '18 at 18:21
GrayedFox
7641229
edited Nov 16 '18 at 18:21
GrayedFox
7641229
edited Nov 16 '18 at 18:21
GrayedFox
7641229
7641229
asked Nov 16 '18 at 13:12
coder firecoder fire
311416
asked Nov 16 '18 at 13:12
coder firecoder fire
311416
asked Nov 16 '18 at 13:12
coder firecoder fire
311416
311416
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Depending on your backend (Ruby on Rails, NodeJS, etc) there will be different approaches. This is an excellent blog post (warning: some colourful language used in that post) which goes over some authentication pitfalls, in particular resetting a password.
To be honest, are you sure you need to have a refresh token at all?
Why not simply issuing a new Bearer token using the updated credentials to the currently active session (the one that made the email/password change request)?
Case 1: authenticated session of user
User has active session(s) and updates their password or email from one of these sessions
- invalidate the sessions that we're not used to update the password/email
- no reason to assume the account has been hacked (they are already logged in,
assuming you also expire your auth tokens in a reasonable time frame) - issue new Bearer token using updated credentials (password/email)
- best practise: send an email to the account
confirming the password change
Case 2: forgotten password
User is logged out and requests a password change (not that you asked for this specifically, but also why no refresh token is needed even if using a special session):
- send the reset link
- user clicks that link, which creates a special session where they are logged in
and can update their password - user updates their password, invalidate all other sessions (if any), issue a
new valid auth token to the current session based on updated credentials - best practise: force them to update the password before taking any other action
Hope this answers your question!
answered Nov 16 '18 at 13:37
GrayedFoxGrayedFox
7641229
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53338628%2fshould-i-refresh-access-token-on-api%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Depending on your backend (Ruby on Rails, NodeJS, etc) there will be different approaches. This is an excellent blog post (warning: some colourful language used in that post) which goes over some authentication pitfalls, in particular resetting a password.
To be honest, are you sure you need to have a refresh token at all?
Why not simply issuing a new Bearer token using the updated credentials to the currently active session (the one that made the email/password change request)?
Case 1: authenticated session of user
User has active session(s) and updates their password or email from one of these sessions
- invalidate the sessions that we're not used to update the password/email
- no reason to assume the account has been hacked (they are already logged in,
assuming you also expire your auth tokens in a reasonable time frame) - issue new Bearer token using updated credentials (password/email)
- best practise: send an email to the account
confirming the password change
Case 2: forgotten password
User is logged out and requests a password change (not that you asked for this specifically, but also why no refresh token is needed even if using a special session):
- send the reset link
- user clicks that link, which creates a special session where they are logged in
and can update their password - user updates their password, invalidate all other sessions (if any), issue a
new valid auth token to the current session based on updated credentials - best practise: force them to update the password before taking any other action
Hope this answers your question!
answered Nov 16 '18 at 13:37
GrayedFoxGrayedFox
7641229
add a comment |
Depending on your backend (Ruby on Rails, NodeJS, etc) there will be different approaches. This is an excellent blog post (warning: some colourful language used in that post) which goes over some authentication pitfalls, in particular resetting a password.
To be honest, are you sure you need to have a refresh token at all?
Why not simply issuing a new Bearer token using the updated credentials to the currently active session (the one that made the email/password change request)?
Case 1: authenticated session of user
User has active session(s) and updates their password or email from one of these sessions
- invalidate the sessions that we're not used to update the password/email
- no reason to assume the account has been hacked (they are already logged in,
assuming you also expire your auth tokens in a reasonable time frame) - issue new Bearer token using updated credentials (password/email)
- best practise: send an email to the account
confirming the password change
Case 2: forgotten password
User is logged out and requests a password change (not that you asked for this specifically, but also why no refresh token is needed even if using a special session):
- send the reset link
- user clicks that link, which creates a special session where they are logged in
and can update their password - user updates their password, invalidate all other sessions (if any), issue a
new valid auth token to the current session based on updated credentials - best practise: force them to update the password before taking any other action
Hope this answers your question!
answered Nov 16 '18 at 13:37
GrayedFoxGrayedFox
7641229
add a comment |
Depending on your backend (Ruby on Rails, NodeJS, etc) there will be different approaches. This is an excellent blog post (warning: some colourful language used in that post) which goes over some authentication pitfalls, in particular resetting a password.
To be honest, are you sure you need to have a refresh token at all?
Why not simply issuing a new Bearer token using the updated credentials to the currently active session (the one that made the email/password change request)?
Case 1: authenticated session of user
User has active session(s) and updates their password or email from one of these sessions
- invalidate the sessions that we're not used to update the password/email
- no reason to assume the account has been hacked (they are already logged in,
assuming you also expire your auth tokens in a reasonable time frame) - issue new Bearer token using updated credentials (password/email)
- best practise: send an email to the account
confirming the password change
Case 2: forgotten password
User is logged out and requests a password change (not that you asked for this specifically, but also why no refresh token is needed even if using a special session):
- send the reset link
- user clicks that link, which creates a special session where they are logged in
and can update their password - user updates their password, invalidate all other sessions (if any), issue a
new valid auth token to the current session based on updated credentials - best practise: force them to update the password before taking any other action
Hope this answers your question!
answered Nov 16 '18 at 13:37
GrayedFoxGrayedFox
7641229
Depending on your backend (Ruby on Rails, NodeJS, etc) there will be different approaches. This is an excellent blog post (warning: some colourful language used in that post) which goes over some authentication pitfalls, in particular resetting a password.
To be honest, are you sure you need to have a refresh token at all?
Why not simply issuing a new Bearer token using the updated credentials to the currently active session (the one that made the email/password change request)?
Case 1: authenticated session of user
User has active session(s) and updates their password or email from one of these sessions
- invalidate the sessions that we're not used to update the password/email
- no reason to assume the account has been hacked (they are already logged in,
assuming you also expire your auth tokens in a reasonable time frame) - issue new Bearer token using updated credentials (password/email)
- best practise: send an email to the account
confirming the password change
Case 2: forgotten password
User is logged out and requests a password change (not that you asked for this specifically, but also why no refresh token is needed even if using a special session):
- send the reset link
- user clicks that link, which creates a special session where they are logged in
and can update their password - user updates their password, invalidate all other sessions (if any), issue a
new valid auth token to the current session based on updated credentials - best practise: force them to update the password before taking any other action
Hope this answers your question!
answered Nov 16 '18 at 13:37
GrayedFoxGrayedFox
7641229
answered Nov 16 '18 at 13:37
GrayedFoxGrayedFox
7641229
answered Nov 16 '18 at 13:37
GrayedFoxGrayedFox
7641229
answered Nov 16 '18 at 13:37
GrayedFoxGrayedFox
7641229
7641229
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53338628%2fshould-i-refresh-access-token-on-api%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
