In IS I retrieve token by call https://wso2is.local:9443/oauth2/authorize?response_type=id_token%20token&client_id=NgTICXFPYnt7ETUm6Fc8NMU8K38a&redirect_uri=http://wso2is.local:8080/playground2/oauth2client&nonce=abc&scope=openid+scope_1+scope_2+scope_3[1].
But when I try get token for all scopes my url becomes very long.
Can I make request e.g scope=openid+global ?
[1] https://docs.wso2.com/display/IS530/Implicit+Client+Profile+with+Playground
That is not supported due to security reasons. Only requested scopes are considered when issuing a token.
Related
I am developing a web application that allows any user to connect with its Salesforce account. I've implemented User-Agent Flow and I obtain correctly access_token and other info but I can't obtain refresh_token, even if I have the correct scopes (api, web, refresh_token, offline_access).
This is the request I use:
https://login.salesforce.com/services/oauth2/authorize?response_type=token&scope=refresh_token&client_id=[MY_CLIENT_ID]&redirect_uri=[MY_REDIRECT_URL]
And my redirect URL is:
http://[MYSITE].com/#/services/oauth2/success
(that corresponds to the host from where I make the call)
This call correctly gives me access_token but not refresh_token.
if I use "https" instead "http" as redirect uri I receive this error:
error=invalid_scope&error_description=the requested scope is not available
From the documentation, I read that:
The refresh token for the user-agent flow is only issued if you
requested scope=refresh_token and one of the following scenarios is
true:
....
The redirect URL host matches the request host and includes the servlet services/oauth2/success.
...
I think to be in this case, what am I doing wrong?
Thanks in advance
Try adding Perform requests at any time (refresh_token, offline_access) under Selected OAuth Scopes in your connected app
It does not appear that I can setup scope in a service config for grant_type of client_credentials.
Is this possible? When requesting a token, I do get back an empty "scope" value. The only way I can get a value to appear is if I pass a query parameter of &scope=foobar. But this does not make sense that the client application is setting the scope.
I want to grant a token with permission to read from API1 and write to API2 but not read/write to API3. It seems I should be able to have a config as scope: [ "java.util.HashSet", [ "api1_read", "api2_write" ] ] basic on clientId config on the cas authorization server.
Then I would image that the resource service, when validating the token would also get a list of scopes allowed.
What am I missing?
You are not missing anything. This capability does not exist and could possibly be added to CAS 6.3 assuming time and sponsorship would be available. Support for scopes are only available as of this writing for OpenID Connect. For OAuth, they would need to be added to the codebase and released.
I've got an OAUTH2 Authentication Server which set a default TTL (3600s) for every new acccess_token.
But in my opinion the access_token TTL should be different for every Resource Server.
Like for a JavaScript Webinterface it should be 3600s, for an Android App it could be one month.
Who decides how long the access_token TTL should be?
Should the GET access_token request from the Client request a custom TTL?
Should the TTL for every Resource be defined in the Service Configuration (along with client_id, client_secret, App Description, ...) on the Authentication server?
The Authorization Server that issues the token is responsible for assigning an expiry time to it. There's no standardized authorization request parameter that the client can use to indicate the preferred TTL. The Authorization Server decides based on a policy that may be based on the client identifier and the associated/configured "permissions" or "trust", parameters available in the Authorization Request (e.g. scope) and other contextual data like HTTP request parameters, time of the day etc.
I'm currently working on an OpenId Server/Client for demonstration purposes and I struggle to understand the following specification.
http://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthRequest
1) The clientApp sends an request (ajax) to the serverApp in order to obtain a session id
2) The clientApp sends an authentication request (ajax) to the serverApp with
{
response_type : "id_token",
scope: "openid profile",
client_id: "clientApp",
redirect_uri : "clientAppAddress/redirecturi",
state: ???,
nonce: ???
}
There are no optional fields for grant_type, username and password (as in RFC6749: Access Token Request). How can I transmit the credentials?
Moreover I don't understand the concept behind "state" and "nonce". The specification says that nonce's value "needs to include per-session state and be unguessable to attackers. One method to achieve this for Web Server Clients is to store a cryptographically random value as an HttpOnly session cookie and use a cryptographic hash of the value as the nonce parameter.", whereas state is used to mitigate CSRF, XSRF "by cryptographically binding the value of this parameter with a browser cookie". Where is the difference between them and how do they increase security? I would use the hash-value of the sessionid (stored in http only cookie, and transmitted to the client in the first request) for both of them?
The actual method of authenticating the user, thus transporting credentials is not part of the OpenID Connect specification. The OpenID Connect specification merely tells you how to transport information about the authentication event and the user to a peer. The means of user authentication is independent of that.
The state parameter is there to correlate request and response and to share context between request and response. One of the things that you would typically associate with the state is the URL that the user is trying to access, so that after a successful authentication response you can redirect to that.
The nonce parameter is to prevent replay attacks since that value should be cached.
Together they are used to prevent Cross Site Request Forgery where an attacker got hold of the id_token and tries to use it against the RP to impersonate the user in the attacker's browser.
It would be better to use other values for state and nonce than directly derived from session_id since you may want to restart authentication from the same session and then nonce replay prevention would block you from reusing it (and distinguish between you and an attacker). Also state should be non-guessable, so not the same as previously used in the same session.
A client credential grant does not return a refresh token (DotNetOpenAuth.OAuth2.AuthorizationServer.PrepareAccessTokenRequest forbids it). But ClientBase.AuthorizeRequest requires it.
Is this a bug in DotNetOpenAuth or am I doing something wrong?
I suppose I can work around by inheriting ClientBase and overriding AuthorizeRequest. Is that the correct thing to do?
Edit: It's not so easy to inherit from ClientBase outside of DotNetOpenAuth because a lot of the stuff you want is internal only. e.g. ErrorUtilities.VerifyProtocol
Edit2: Just read the draft OAuth 2 spec (draft 25) referred to in DotNetOpenAuth.OAuth2.AuthorizationServer.PrepareAccessTokenRequest and I can't find where it disallows refresh tokens for Client credential grant type. Maybe they changed it?
Google returns Refresh Token if you request it. Provide parameter in query string access_type=offline.
In my case I had to amend default Authorization Endpoint URL to: https://accounts.google.com/o/oauth2/auth?access_type=offline
Google Api C# example using DotNetOpenAuth:
private WebServerClient GetClient()
{
return new WebServerClient(
new AuthorizationServerDescription
{
AuthorizationEndpoint = new Uri("https://accounts.google.com/o/oauth2/auth?access_type=offline"),
TokenEndpoint = new Uri("https://accounts.google.com/o/oauth2/token"),
ProtocolVersion = ProtocolVersion.V20,
},
clientIdentifier: this.settings.GoogleApisClientIdentifier,
clientSecret: this.settings.GoogleApisClientSecret
);
}
NOTE from my experience: This works only for the First request.
See Google Documentation.
I'm not sure why you say that ClientBase.AuthorizeRequest requires it. Firstly, there is an overload that only takes an access token, so it doesn't even ask for a refresh token. The overload you may have tried accepts an IAuthorizationState object, which may or may not include a refresh token, and it appears that that method only looks for a refresh token if the access token has expired. Since an expired access token can't be used, it tries to refresh it and throws if it can't. It seems reasonable to me.
Whichever method overload you choose to call, your calling mode must either avoid using expired access tokens or be prepared to respond to the exceptions that are thrown when DotNetOpenAuth or the resource server determines that they are expired or revoked. In fact since tokens can be revoked before they expire, it's a good idea to always be prepared for that.
The OAuth 2 spec draft 25 does in fact indicate that a refresh token should not be included in a response to the client credentials grant. From section 4.4.3:
4.4.3. Access Token Response
If the access token request is valid and authorized, the authorization server issues an access token as described in Section 5.1. A refresh token SHOULD NOT be included. If the request failed client authentication or is invalid, the authorization server returns an error response as described in Section 5.2.