WSO2IS:Token generated with grant_type value password of one user, coming active for another users
up vote
0
down vote
favorite
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
add a comment |
up vote
0
down vote
favorite
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
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
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
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 at 21:04
r08
186
186
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
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.
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
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.
add a comment |
up vote
0
down vote
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.
add a comment |
up vote
0
down vote
up vote
0
down vote
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.
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 at 4:40
Maduranga Siriwardena
6751619
6751619
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.
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%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