Mixing
WSO2IS:Token generated with grant_type value password of one user, coming active for another users
I am working on WSO2IS 5.6.0 to generate and validate access token for the multi-tenant(each tenants having one or more users) web application by using Service Provider configuration.
Generate Token Request:
Url:https://localhost:9443/oauth2/token
Method: POST
Header:Content-Type:application/x-www-form-urlencoded
Authorization:client_credentials
Body:
grant_type:password
username:
password:
Validate Token Request:
Authorizatin Basic :
Header:Content-Type:application/x-www-form-urlencoded
Body:token:
everything working properly but while validating generated token from one user credential, coming active for another user also.
what I should do to generate/validate the user based token.
Please give me advice.
java oauth-2.0 wso2is
asked Nov 19 '18 at 21:04
r08r08
206
add a comment |
I am working on WSO2IS 5.6.0 to generate and validate access token for the multi-tenant(each tenants having one or more users) web application by using Service Provider configuration.
Generate Token Request:
Url:https://localhost:9443/oauth2/token
Method: POST
Header:Content-Type:application/x-www-form-urlencoded
Authorization:client_credentials
Body:
grant_type:password
username:
password:
Validate Token Request:
Authorizatin Basic :
Header:Content-Type:application/x-www-form-urlencoded
Body:token:
everything working properly but while validating generated token from one user credential, coming active for another user also.
what I should do to generate/validate the user based token.
Please give me advice.
java oauth-2.0 wso2is
asked Nov 19 '18 at 21:04
r08r08
206
add a comment |
I am working on WSO2IS 5.6.0 to generate and validate access token for the multi-tenant(each tenants having one or more users) web application by using Service Provider configuration.
Generate Token Request:
Url:https://localhost:9443/oauth2/token
Method: POST
Header:Content-Type:application/x-www-form-urlencoded
Authorization:client_credentials
Body:
grant_type:password
username:
password:
Validate Token Request:
Authorizatin Basic :
Header:Content-Type:application/x-www-form-urlencoded
Body:token:
everything working properly but while validating generated token from one user credential, coming active for another user also.
what I should do to generate/validate the user based token.
Please give me advice.
java oauth-2.0 wso2is
asked Nov 19 '18 at 21:04
r08r08
206
I am working on WSO2IS 5.6.0 to generate and validate access token for the multi-tenant(each tenants having one or more users) web application by using Service Provider configuration.
Generate Token Request:
Url:https://localhost:9443/oauth2/token
Method: POST
Header:Content-Type:application/x-www-form-urlencoded
Authorization:client_credentials
Body:
grant_type:password
username:
password:
Validate Token Request:
Authorizatin Basic :
Header:Content-Type:application/x-www-form-urlencoded
Body:token:
everything working properly but while validating generated token from one user credential, coming active for another user also.
what I should do to generate/validate the user based token.
Please give me advice.
java oauth-2.0 wso2is
java oauth-2.0 wso2is
asked Nov 19 '18 at 21:04
r08r08
206
asked Nov 19 '18 at 21:04
r08r08
206
asked Nov 19 '18 at 21:04
r08r08
206
asked Nov 19 '18 at 21:04
r08r08
206
asked Nov 19 '18 at 21:04
r08r08
206
206
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Hope your problem is the credentials sent as the Authorization header of the token validation request and the token sent for the validation does not belong to the same user.
According to OAuth 2.0 Token Introspection
To prevent token scanning attacks, the endpoint MUST also require some form of authorization to access this endpoint, such as client authentication as described in OAuth 2.0 [RFC6749] or a separate OAuth 2.0 access token such as the bearer token described in OAuth 2.0 Bearer Token Usage [RFC6750]. The methods of managing and validating these authentication credentials are out of scope of this specification.
So the introspection endpoint needs to be secured with some sort of authentication mechanism. WSO2 Identity Server supports Basic authentication with username/password and Bearer authentication. But we can't expect to get the same user's credentials as the Authorization header because, at the point of validating the token, there is no way to get the token owner's credentials or an active token belonging to the user.
So Identity Server expects credentials of a user that has /permission/admin/manage/identity/applicationmgt/view permission for the authorization of the endpoint.
Refer to WSO2 Documentation for more details.
answered Nov 23 '18 at 4:40
Maduranga SiriwardenaMaduranga Siriwardena
7141619
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%2f53382599%2fwso2istoken-generated-with-grant-type-value-password-of-one-user-coming-active%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
Hope your problem is the credentials sent as the Authorization header of the token validation request and the token sent for the validation does not belong to the same user.
According to OAuth 2.0 Token Introspection
To prevent token scanning attacks, the endpoint MUST also require some form of authorization to access this endpoint, such as client authentication as described in OAuth 2.0 [RFC6749] or a separate OAuth 2.0 access token such as the bearer token described in OAuth 2.0 Bearer Token Usage [RFC6750]. The methods of managing and validating these authentication credentials are out of scope of this specification.
So the introspection endpoint needs to be secured with some sort of authentication mechanism. WSO2 Identity Server supports Basic authentication with username/password and Bearer authentication. But we can't expect to get the same user's credentials as the Authorization header because, at the point of validating the token, there is no way to get the token owner's credentials or an active token belonging to the user.
So Identity Server expects credentials of a user that has /permission/admin/manage/identity/applicationmgt/view permission for the authorization of the endpoint.
Refer to WSO2 Documentation for more details.
answered Nov 23 '18 at 4:40
Maduranga SiriwardenaMaduranga Siriwardena
7141619
add a comment |
Hope your problem is the credentials sent as the Authorization header of the token validation request and the token sent for the validation does not belong to the same user.
According to OAuth 2.0 Token Introspection
To prevent token scanning attacks, the endpoint MUST also require some form of authorization to access this endpoint, such as client authentication as described in OAuth 2.0 [RFC6749] or a separate OAuth 2.0 access token such as the bearer token described in OAuth 2.0 Bearer Token Usage [RFC6750]. The methods of managing and validating these authentication credentials are out of scope of this specification.
So the introspection endpoint needs to be secured with some sort of authentication mechanism. WSO2 Identity Server supports Basic authentication with username/password and Bearer authentication. But we can't expect to get the same user's credentials as the Authorization header because, at the point of validating the token, there is no way to get the token owner's credentials or an active token belonging to the user.
So Identity Server expects credentials of a user that has /permission/admin/manage/identity/applicationmgt/view permission for the authorization of the endpoint.
Refer to WSO2 Documentation for more details.
answered Nov 23 '18 at 4:40
Maduranga SiriwardenaMaduranga Siriwardena
7141619
add a comment |
Hope your problem is the credentials sent as the Authorization header of the token validation request and the token sent for the validation does not belong to the same user.
According to OAuth 2.0 Token Introspection
To prevent token scanning attacks, the endpoint MUST also require some form of authorization to access this endpoint, such as client authentication as described in OAuth 2.0 [RFC6749] or a separate OAuth 2.0 access token such as the bearer token described in OAuth 2.0 Bearer Token Usage [RFC6750]. The methods of managing and validating these authentication credentials are out of scope of this specification.
So the introspection endpoint needs to be secured with some sort of authentication mechanism. WSO2 Identity Server supports Basic authentication with username/password and Bearer authentication. But we can't expect to get the same user's credentials as the Authorization header because, at the point of validating the token, there is no way to get the token owner's credentials or an active token belonging to the user.
So Identity Server expects credentials of a user that has /permission/admin/manage/identity/applicationmgt/view permission for the authorization of the endpoint.
Refer to WSO2 Documentation for more details.
answered Nov 23 '18 at 4:40
Maduranga SiriwardenaMaduranga Siriwardena
7141619
Hope your problem is the credentials sent as the Authorization header of the token validation request and the token sent for the validation does not belong to the same user.
According to OAuth 2.0 Token Introspection
To prevent token scanning attacks, the endpoint MUST also require some form of authorization to access this endpoint, such as client authentication as described in OAuth 2.0 [RFC6749] or a separate OAuth 2.0 access token such as the bearer token described in OAuth 2.0 Bearer Token Usage [RFC6750]. The methods of managing and validating these authentication credentials are out of scope of this specification.
So the introspection endpoint needs to be secured with some sort of authentication mechanism. WSO2 Identity Server supports Basic authentication with username/password and Bearer authentication. But we can't expect to get the same user's credentials as the Authorization header because, at the point of validating the token, there is no way to get the token owner's credentials or an active token belonging to the user.
So Identity Server expects credentials of a user that has /permission/admin/manage/identity/applicationmgt/view permission for the authorization of the endpoint.
Refer to WSO2 Documentation for more details.
answered Nov 23 '18 at 4:40
Maduranga SiriwardenaMaduranga Siriwardena
7141619
answered Nov 23 '18 at 4:40
Maduranga SiriwardenaMaduranga Siriwardena
7141619
answered Nov 23 '18 at 4:40
Maduranga SiriwardenaMaduranga Siriwardena
7141619
answered Nov 23 '18 at 4:40
Maduranga SiriwardenaMaduranga Siriwardena
7141619
7141619
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%2f53382599%2fwso2istoken-generated-with-grant-type-value-password-of-one-user-coming-active%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
