Oauth - What Kind of Permissions should be given in default login token?
I'm working on an authentication system for a web application I am making. I want to allow other apps to connect to the data stored in mine (using an OAuth system).
I've been reading about how OAuth works here: https://www.oauth.com/oauth2-servers/background/
Most of it makes sense, however I do have one problem:
How do I make it so the user does not have to grant access to my own mobile apps?
In other words, how can I make it so the server automatically grants certain permissions to my mobile apps?
I assume part of this involves creating a client ID and client secret for those apps, just like the others, but how could I securely bypass the grant from those applications?
I'm not sure if I'm doing this correctly, because in my API I have a signIn endpoint that takes a username and password and returns an auth token.
Should I just not have a signIn endpoint, and instead just have a token validator that hands off to the OAuth system if the token is invalid?
I know that's a lot of questions, but I want to get this right since the authentication system is so important to security.
php python rest oauth oauth-2.0
asked Dec 27 '18 at 15:12
Caleb H.
33811
add a comment |
I'm working on an authentication system for a web application I am making. I want to allow other apps to connect to the data stored in mine (using an OAuth system).
I've been reading about how OAuth works here: https://www.oauth.com/oauth2-servers/background/
Most of it makes sense, however I do have one problem:
How do I make it so the user does not have to grant access to my own mobile apps?
In other words, how can I make it so the server automatically grants certain permissions to my mobile apps?
I assume part of this involves creating a client ID and client secret for those apps, just like the others, but how could I securely bypass the grant from those applications?
I'm not sure if I'm doing this correctly, because in my API I have a signIn endpoint that takes a username and password and returns an auth token.
Should I just not have a signIn endpoint, and instead just have a token validator that hands off to the OAuth system if the token is invalid?
I know that's a lot of questions, but I want to get this right since the authentication system is so important to security.
php python rest oauth oauth-2.0
asked Dec 27 '18 at 15:12
Caleb H.
33811
accesspermissions should be fine
– Evhz
Dec 27 '18 at 15:40
add a comment |
I'm working on an authentication system for a web application I am making. I want to allow other apps to connect to the data stored in mine (using an OAuth system).
I've been reading about how OAuth works here: https://www.oauth.com/oauth2-servers/background/
Most of it makes sense, however I do have one problem:
How do I make it so the user does not have to grant access to my own mobile apps?
In other words, how can I make it so the server automatically grants certain permissions to my mobile apps?
I assume part of this involves creating a client ID and client secret for those apps, just like the others, but how could I securely bypass the grant from those applications?
I'm not sure if I'm doing this correctly, because in my API I have a signIn endpoint that takes a username and password and returns an auth token.
Should I just not have a signIn endpoint, and instead just have a token validator that hands off to the OAuth system if the token is invalid?
I know that's a lot of questions, but I want to get this right since the authentication system is so important to security.
php python rest oauth oauth-2.0
asked Dec 27 '18 at 15:12
Caleb H.
33811
I'm working on an authentication system for a web application I am making. I want to allow other apps to connect to the data stored in mine (using an OAuth system).
I've been reading about how OAuth works here: https://www.oauth.com/oauth2-servers/background/
Most of it makes sense, however I do have one problem:
How do I make it so the user does not have to grant access to my own mobile apps?
In other words, how can I make it so the server automatically grants certain permissions to my mobile apps?
I assume part of this involves creating a client ID and client secret for those apps, just like the others, but how could I securely bypass the grant from those applications?
I'm not sure if I'm doing this correctly, because in my API I have a signIn endpoint that takes a username and password and returns an auth token.
Should I just not have a signIn endpoint, and instead just have a token validator that hands off to the OAuth system if the token is invalid?
I know that's a lot of questions, but I want to get this right since the authentication system is so important to security.
php python rest oauth oauth-2.0
php python rest oauth oauth-2.0
asked Dec 27 '18 at 15:12
Caleb H.
33811
asked Dec 27 '18 at 15:12
Caleb H.
33811
asked Dec 27 '18 at 15:12
Caleb H.
33811
asked Dec 27 '18 at 15:12
Caleb H.
33811
asked Dec 27 '18 at 15:12
Caleb H.
33811
33811
accesspermissions should be fine
– Evhz
Dec 27 '18 at 15:40
add a comment |
accesspermissions should be fine
– Evhz
Dec 27 '18 at 15:40
access permissions should be fine– Evhz
Dec 27 '18 at 15:40
access permissions should be fine– Evhz
Dec 27 '18 at 15:40
add a comment |
1 Answer
1
active
oldest
votes
For the first question about the mobile clients, there is the OAuth2 for Native Apps RFC which discusses the topic. In short, you should use the authorization code grant with PKCE and refresh tokens, so your mobile apps need to ask for authorization just once. To do it, your mobile apps will need to be registrated OAuth2 clients and the token endpoint should be configured not to require secret (since you cannot keep secrets in mobile apps).
For the second part, one of the benefits of the OAuth2 protocol is that only the auth server gets user credentials - not the applications. It makes the credentials harder to get compromised and allows users to delegate only certain rights (scopes). So it would be good to stick to some of the basic OAuth2 flows (auth code, implicit, hybrid) and not to use your own endpoint for authentication. It will make your application safer and maybe even easier to use (if you use things like SSO).
answered Dec 27 '18 at 19:00
Ján Halaša
4,0621316
Thanks for the answer! I would also like to ask how OAuth works without a client secret. Since the client ID is considered public information, how do you make sure you are not impersonated?
– Caleb H.
Dec 27 '18 at 19:42
I think if you use Claimed "https" Scheme for redirect URIs, operating systems should guarantee the identity of the app using a given client_id. So an attacker's app should not be able to use your client_id and get an auth code. But I don't know how it's implemented in operating systems.
– Ján Halaša
Dec 27 '18 at 21:31
Ok, and lastly, should I have asignUpendpoint, so my apps can create accounts from the device?
– Caleb H.
Dec 28 '18 at 3:35
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%2f53947162%2foauth-what-kind-of-permissions-should-be-given-in-default-login-token%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
For the first question about the mobile clients, there is the OAuth2 for Native Apps RFC which discusses the topic. In short, you should use the authorization code grant with PKCE and refresh tokens, so your mobile apps need to ask for authorization just once. To do it, your mobile apps will need to be registrated OAuth2 clients and the token endpoint should be configured not to require secret (since you cannot keep secrets in mobile apps).
For the second part, one of the benefits of the OAuth2 protocol is that only the auth server gets user credentials - not the applications. It makes the credentials harder to get compromised and allows users to delegate only certain rights (scopes). So it would be good to stick to some of the basic OAuth2 flows (auth code, implicit, hybrid) and not to use your own endpoint for authentication. It will make your application safer and maybe even easier to use (if you use things like SSO).
answered Dec 27 '18 at 19:00
Ján Halaša
4,0621316
Thanks for the answer! I would also like to ask how OAuth works without a client secret. Since the client ID is considered public information, how do you make sure you are not impersonated?
– Caleb H.
Dec 27 '18 at 19:42
I think if you use Claimed "https" Scheme for redirect URIs, operating systems should guarantee the identity of the app using a given client_id. So an attacker's app should not be able to use your client_id and get an auth code. But I don't know how it's implemented in operating systems.
– Ján Halaša
Dec 27 '18 at 21:31
Ok, and lastly, should I have asignUpendpoint, so my apps can create accounts from the device?
– Caleb H.
Dec 28 '18 at 3:35
add a comment |
For the first question about the mobile clients, there is the OAuth2 for Native Apps RFC which discusses the topic. In short, you should use the authorization code grant with PKCE and refresh tokens, so your mobile apps need to ask for authorization just once. To do it, your mobile apps will need to be registrated OAuth2 clients and the token endpoint should be configured not to require secret (since you cannot keep secrets in mobile apps).
For the second part, one of the benefits of the OAuth2 protocol is that only the auth server gets user credentials - not the applications. It makes the credentials harder to get compromised and allows users to delegate only certain rights (scopes). So it would be good to stick to some of the basic OAuth2 flows (auth code, implicit, hybrid) and not to use your own endpoint for authentication. It will make your application safer and maybe even easier to use (if you use things like SSO).
answered Dec 27 '18 at 19:00
Ján Halaša
4,0621316
Thanks for the answer! I would also like to ask how OAuth works without a client secret. Since the client ID is considered public information, how do you make sure you are not impersonated?
– Caleb H.
Dec 27 '18 at 19:42
I think if you use Claimed "https" Scheme for redirect URIs, operating systems should guarantee the identity of the app using a given client_id. So an attacker's app should not be able to use your client_id and get an auth code. But I don't know how it's implemented in operating systems.
– Ján Halaša
Dec 27 '18 at 21:31
Ok, and lastly, should I have asignUpendpoint, so my apps can create accounts from the device?
– Caleb H.
Dec 28 '18 at 3:35
add a comment |
For the first question about the mobile clients, there is the OAuth2 for Native Apps RFC which discusses the topic. In short, you should use the authorization code grant with PKCE and refresh tokens, so your mobile apps need to ask for authorization just once. To do it, your mobile apps will need to be registrated OAuth2 clients and the token endpoint should be configured not to require secret (since you cannot keep secrets in mobile apps).
For the second part, one of the benefits of the OAuth2 protocol is that only the auth server gets user credentials - not the applications. It makes the credentials harder to get compromised and allows users to delegate only certain rights (scopes). So it would be good to stick to some of the basic OAuth2 flows (auth code, implicit, hybrid) and not to use your own endpoint for authentication. It will make your application safer and maybe even easier to use (if you use things like SSO).
answered Dec 27 '18 at 19:00
Ján Halaša
4,0621316
For the first question about the mobile clients, there is the OAuth2 for Native Apps RFC which discusses the topic. In short, you should use the authorization code grant with PKCE and refresh tokens, so your mobile apps need to ask for authorization just once. To do it, your mobile apps will need to be registrated OAuth2 clients and the token endpoint should be configured not to require secret (since you cannot keep secrets in mobile apps).
For the second part, one of the benefits of the OAuth2 protocol is that only the auth server gets user credentials - not the applications. It makes the credentials harder to get compromised and allows users to delegate only certain rights (scopes). So it would be good to stick to some of the basic OAuth2 flows (auth code, implicit, hybrid) and not to use your own endpoint for authentication. It will make your application safer and maybe even easier to use (if you use things like SSO).
answered Dec 27 '18 at 19:00
Ján Halaša
4,0621316
answered Dec 27 '18 at 19:00
Ján Halaša
4,0621316
answered Dec 27 '18 at 19:00
Ján Halaša
4,0621316
answered Dec 27 '18 at 19:00
Ján Halaša
4,0621316
4,0621316
Thanks for the answer! I would also like to ask how OAuth works without a client secret. Since the client ID is considered public information, how do you make sure you are not impersonated?
– Caleb H.
Dec 27 '18 at 19:42
I think if you use Claimed "https" Scheme for redirect URIs, operating systems should guarantee the identity of the app using a given client_id. So an attacker's app should not be able to use your client_id and get an auth code. But I don't know how it's implemented in operating systems.
– Ján Halaša
Dec 27 '18 at 21:31
Ok, and lastly, should I have asignUpendpoint, so my apps can create accounts from the device?
– Caleb H.
Dec 28 '18 at 3:35
add a comment |
Thanks for the answer! I would also like to ask how OAuth works without a client secret. Since the client ID is considered public information, how do you make sure you are not impersonated?
– Caleb H.
Dec 27 '18 at 19:42
I think if you use Claimed "https" Scheme for redirect URIs, operating systems should guarantee the identity of the app using a given client_id. So an attacker's app should not be able to use your client_id and get an auth code. But I don't know how it's implemented in operating systems.
– Ján Halaša
Dec 27 '18 at 21:31
Ok, and lastly, should I have asignUpendpoint, so my apps can create accounts from the device?
– Caleb H.
Dec 28 '18 at 3:35
Thanks for the answer! I would also like to ask how OAuth works without a client secret. Since the client ID is considered public information, how do you make sure you are not impersonated?
– Caleb H.
Dec 27 '18 at 19:42
Thanks for the answer! I would also like to ask how OAuth works without a client secret. Since the client ID is considered public information, how do you make sure you are not impersonated?
– Caleb H.
Dec 27 '18 at 19:42
I think if you use Claimed "https" Scheme for redirect URIs, operating systems should guarantee the identity of the app using a given client_id. So an attacker's app should not be able to use your client_id and get an auth code. But I don't know how it's implemented in operating systems.
– Ján Halaša
Dec 27 '18 at 21:31
I think if you use Claimed "https" Scheme for redirect URIs, operating systems should guarantee the identity of the app using a given client_id. So an attacker's app should not be able to use your client_id and get an auth code. But I don't know how it's implemented in operating systems.
– Ján Halaša
Dec 27 '18 at 21:31
Ok, and lastly, should I have a
signUp endpoint, so my apps can create accounts from the device?– Caleb H.
Dec 28 '18 at 3:35
Ok, and lastly, should I have a
signUp endpoint, so my apps can create accounts from the device?– Caleb H.
Dec 28 '18 at 3:35
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2f53947162%2foauth-what-kind-of-permissions-should-be-given-in-default-login-token%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
accesspermissions should be fine– Evhz
Dec 27 '18 at 15:40