How to change "scopes" with Auth2.0 (Connexion, Swagger) - oauth-2.0

I am tying to understand this authentication-example with OAuth2.0 and am stuck at the scopes part: https://github.com/zalando/connexion/tree/master/examples/swagger2/oauth2
In app.yaml, we define 'uid' to be the necessary scope for our application:
/secret:
get:
summary: Return secret string
operationId: app.get_secret
responses:
200:
description: secret response
schema:
type: string
security:
# enable authentication and require the "uid" scope for this endpoint
- oauth2: ['uid']
In the security-definitions of app.yaml, the "uid" is again in the scopes section and is required as an answer from the x-tokenInfoUrl (which I need).
securityDefinitions:
oauth2:
type: oauth2
flow: implicit
authorizationUrl: https://example.com/oauth2/dialog
x-tokenInfoUrl: http://localhost:7979/tokeninfo
scopes:
uid: Unique identifier of the user accessing the service.
In our mock application for tokeninfo (mock_tokeninfo.yaml), we see that "uid" is returned and that the scope is actually "uid", which we wanted.
return {'uid': uid, 'scope': ['uid']}
And finally in mock_tokeninfo.yaml, we have the "uid" and the scope in the response:
responses:
200:
description: Token info object
schema:
type: object
properties:
uid:
type: string
scope:
type: array
items:
type: string
So what I understand now is that when app.py starts on port 8080 and I call localhost on port 8080 with "/secret", the security-part checks what is required and sees "uid". It follows the x-tokenInfoUrl on localhost:7979, where we started our mock_tokeninfo application and it returns to us a "uid" and the scope "uid".
Now my question is the following: I have now an own identity provider and would like to access the userinfo from there. I changed the x-tokenInfoUrl to something like this:
https://<my_idp>/<some_paths>/userinfo
and when I make curl like this: curl -H 'Authorization: Bearer <access_token>‘ https://<IDP>/<some_paths>/userinfo, it works and I get a response that looks like this:
{"mail":"<my_email>",
"name":"<my_name>"}
Now as far as I understand, I would only need to change "uid" to e.g. "mail" and it should return my email to me, but no: I get
403 - forbidden
provided token does not have the required scope
Content-Type: application/problem+json
I don't understand why I don't have the required scope - it simply does not make sense to me. Can somebody please explain, how can I get my information out of my identity provider? I also checked and in my authorization email with my id and secret, it says that scope is <some_keyword>, but this keyword also results in 403 like everything else.
Ps: I've already passed my certificate to the identity provider, so this should not be the problem.
EDIT:
Please - help me you intelligent ppl of StackOverflow :(
I found those "MUST naming conventions for scopes": https://opensource.zalando.com/restful-api-guidelines/
But it did not help as well.
I checked, if the header is actually redirected and it was.
I found this statement: "However, to make this explicit you should assign the uid pseudo permission in this case. It is the user id and always available as OAuth2 default scope", but again - if this is a pseudo-permission, how do I do a normal scope?
In every example that I find (the pet-read/write example is the most common one), the scope-variables seem to have custom names... (https://swagger.io/docs/specification/authentication/oauth2/)
Here the documentation for the "security"-section, maybe I misunderstand something: https://connexion.readthedocs.io/en/latest/security.html

So the solution is finally found. The problem is that the documentation was not updated. This is the link to the documentation:
https://connexion.readthedocs.io/en/latest/security.html#oauth-2-authentication-and-authorization
And it says that:
The sub property of the Token Info response will be passed in the user argument to the handler function.
Further investigation resulted in finding this commit message of the connexion-package:
https://github.com/mnylen/connexion/commit/1818c34ecbdd6833a6c8cde61021ece38b59d978
Which updates the insufficient description by that phrase:
The Token Info response will be passed in the token_info argument to the handler
function. The sub property of the Token Info response will be passed in the user
argument to the handler function.
So putting the information about "No Scopes" from here:
https://swagger.io/docs/specification/authentication/oauth2/
together with the information from the commit-message, we can change our example like following:
app.yaml:
security:
# enable authentication and require the "uid" scope for this endpoint
- oauth2: []
securityDefinitions:
oauth2:
type: oauth2
x-tokenInfoUrl: https://<my_idp>/<some_paths>/userinfo
scopes: {}
And instead of using "user", we use "token_info" in our function:
app.py:
get_secret(token_info):
return token_info
This way, I got all the information that was passed by our identity-provider.
Thank you all for thinking with me :) Hope, you find this useful.

Related

omniauth_openid_connect gem - Authentication failure! invalid_request: Rack::OAuth2::Client::Error, invalid_request :: Client credentials are invalid

Im using this gem to add Omniauth OpenID with a provider.
I configured the gem in the Devise Initializer, everything seems to be correct:
config.omniauth :openid_connect,
{
name: :openid_connect,
scope: %i[openid profile groups_rewardops scope_rewardops],
issuer: ConfigSettings.desjardins.issuer_url,
response_type: :code,
uid_field: 'sub',
response_mode: :query,
discovery: true,
send_scope_to_token_endpoint: false,
client_options:
{
port: 443,
scheme: "https",
host: ConfigSettings.desjardins.host,
authorization_endpoint: "/affwebservices/CASSO/oidc/rewardops/authorize",
token_endpoint: "/affwebservices/CASSO/oidc/rewardops/token",
userinfo_endpoint: "/affwebservices/CASSO/oidc/rewardops/userinfo",
identifier: ConfigSettings.desjardins.client_id,
secret: ConfigSettings.desjardins.client_secret,
redirect_uri: "#{ConfigSettings.api.base_url}front_end/users/auth/openid_connect/callback",
},
}
The flow I have atm is that the user can log in and grant access from the provider, then the provider sends a request to my devise callback url with the nonce, code and state. At this point everything seems to be correct but that request ends in failure when trying to generate the access_token with the following error:
ERROR -- omniauth: (openid_connect) Authentication failure! invalid_request: Rack::OAuth2::Client::Error, invalid_request :: Client credentials are invalid.
Im sure the identifier and the secret are correct, don't understand what's going on.
Since Im using discovery mode all the configs of the provider are in the .well-known you can check it here
Im blocked without ideas about how to debug the error. Checking at Rack::OAuth2 to see where the error is comming from I found this that says:
invalid_request: "The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats the same parameter, uses more than one method for including an access token, or is otherwise malformed.",
It seems for some reason the access token request is malformed, but not sure what else apart of identifier and secret should I have in mind? I have seen many other examples of configuration and mine seems to be correct.
Since you are sure your credentials are correct, I suspect there is mismatch between the authentication method being used and the methods supported by the provider. Checking the .well-known config, I see this provider only supports client_secret_post. In your omniauth config, I see no options being passed to specify the authentication method. When I dive down into the code, I see that the underlying oauth2 gem defaults to using basic auth, which uses the indentifier and secret to construct an Authentication header. See: source code here
client_auth_method = args.first || options.delete(:client_auth_method).try(:to_sym) || :basic
case client_auth_method
when :basic
cred = Base64.strict_encode64 [
Util.www_form_url_encode(identifier),
Util.www_form_url_encode(secret)
].join(':')
headers.merge!(
'Authorization' => "Basic #{cred}"
)
In the client_secret_post authentication method, instead of providing client secret in the header, the client authorizes itself providing the secret in the HTTP request body as a form parameter. So this provider is not seeing your credentials. You could verify this by looking at the logs of the token endpoint request, which won't be visible in the browser, but rather from your rails BE to the the provider's server.
Try passing a client_auth_method in the client_options hash in your omniauth config. If you look at the case statement in the code I linked to above, there doesn't seem to be a named option for client_secret_post, but it is the default case. Any value for client_auth_method looks like it would work, but I would still use client_secret_post.

Can't deploy an app to Intune store via graph API - DeviceManagementApps.ReadWrite.All is an invalid scope?

We want to enable uploading apps to the Intune store via an API.
I saw this example on GitHub, and want to do something similar in JS, so I've tried using the same REST calls.
The problem is, I can't seem to make the https://graph.microsoft.com/beta/deviceAppManagement/mobileApps request properly - I always get 401. When making the same request via the Graph API Explorer it works fine.
I tried fixing my permissions, and I'm kinda stuck getting the correct token.
I did the following steps with an admin account, on both the "common" and our own tennant:
Called the admin consent - https://login.microsoftonline.com/nativeflow.onmicrosoft.com/adminconsent?client_id=<ID>&redirect_uri=<URI>
Got authorization from the user - https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=<ID>&response_type=code&redirect_uri=<URI>&response_mode=query&scope=DeviceManagementApps.ReadWrite.All
POST request to get the actual token -
https://login.microsoftonline.com/nativeflow.onmicrosoft.com/oauth2/v2.0/token
with the following body:
client_id: <ID>
scope: https://graph.microsoft.com/.default
client_secret: <secret>
grant_type: client_credentials
requested_token_use: on_behalf_of
code: <The code I got in step 2>
I tried changing the scope in step 3 to https://graph.microsoft.com/DeviceManagementApps.ReadWrite.All or simply to DeviceManagementApps.ReadWrite.All, but it says that it's not a valid scope.
I got a token in step 3, but when I try calling the actual API I receive this error:
{
ErrorCode:"Forbidden",
Message:{
_version: 3,
Message: "An error has occurred - Operation ID (for customer support): 00000000-0000-0000-0000-000000000000 - Activity ID: 7b5c3841-976d-4509-b946-f7fdabd047d7 - Url: https://fef.msub02.manage.microsoft.com/StatelessAppMetadataFEService/deviceAppManagement/mobileApps?api-version=5018-05-02",
CustomApiErrorPhrase: "",
RetryAfter: null,
ErrorSourceService: "",
HttpHeaders: {"WWW-Authenticate":"Bearer realm=urn:intune:service,f0f3c450-59bf-4f0d-b1b2-0ef84ddfe3c7"}
},
Target:null,
Details:null,
InnerError:null,
InstanceAnnotations:[]
}
So yeah, I'm pretty much stuck. Anyone have any experience with it? I've tried making the calls in Postman, curl and via code, but nothing works.
Cheers :)
You have a couple issues going on:
You're using the Authorization Code Grant workflow but requesting Client Credentials.
The scope Device.ReadWrite.All is an application scope, it is only applicable to Client Credentials. It isn't a valid Delegated scope so it will return an error when you attempt to authenticate a user (aka delegate) using Device.ReadWrite.All.
Your body is using key:value but it should be using standard form encoding (key=value).
To get this working, you need to request a token without a user. This is done by skipping your 2nd step and moving directly to retrieving a token (body line-breaks are only for readability):
POST https://login.microsoftonline.com/nativeflow.onmicrosoft.com/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded
client_id={id}
&client_secret={secret}
&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default
&grant_type=client_credentials

Why does API Gateway not have permissions for my Authorizer lambda when using Swagger?

I have an API defined using Swagger, which defines the following API Key authorizer:
securityDefinitions:
api_key:
type: apiKey
name: x-api-key
in: header
x-amazon-apigateway-authtype: "oauth2"
x-amazon-apigateway-authorizer:
type: token
authorizerUri: arn:aws:apigateway:eu-west-1:lambda:path/2015-03-31/functions/arn:aws:lambda:eu-west-1:[accountid]:function:ApiKeyAuthorizerLambdaFunction/invocations
authorizerResultTtlInSeconds: 0
However, when I pass this Swagger definition into my CloudFormation script and call an endpoint secured with this authorizer, I get a 500. The API Gateway logs show the following:
Incoming identity: ***key
Execution failed due to configuration error: Invalid permissions on Lambda function
Execution failed due to configuration error: Authorizer error
Note that I have given API Gateway permission to execute this lambda:
LambdaPermissionAuthorizerApiGateway:
Type: AWS::Lambda::Permission
Properties:
FunctionName:
Fn::GetAtt:
- ApiKeyAuthorizerLambdaFunction
- Arn
Action: lambda:InvokeFunction
Principal: apigateway.amazonaws.com
In fact, when I compare the CloudFormation script which Serverless generates for authoized endpoints (using Serverless's notation) with my own CloudFormation script using Swagger, I see little difference between them, except that my authorizer is defined with Swagger rather than directly as a CF resource.
Can anyone shed any light on this? Is this a bug when using Swagger with CloudFormation?
Can you try setting the authorizerCredentials parameter of your x-amazon-apigateway-authorizer to a valid IAM role that has permission to execute the authorizer lambda? Not sure the standard AWS::Lambda::Permission applies for this, though you probably want to keep it for now just in case it is still required.
The x-amazon-apigateway-authorizer docs show an example.

BadRequest when calling ProcessUserAuthorization after requesting "plus.login" scope

I have problems while updating code to new scope. Currently I use userinfo.profile and everything works Ok.
According to Google+ OAuth 2.0 scopes new plus.me scope allows application to know who user is, and plus.login also gives additional access (to age, language, circles, ...).
If I replace userinfo.profile with plus.me - everything works Ok: method WebServerClient.RequestUserAuthorization authorizes user and ProcessUserAuthorization gives me a token.
But if I ask plus.login scope instead - Google adds additional query parameters to my callback and next call to WebServerClient.ProcessUserAuthorization fails , because implementation uses current rul to make new redirect_url, striping "known" parameters and leaving "new unknown" Google parameters. his redirect_url doesn't match on registered in Google Api Console and Google server returns 400 response.
Here is success response from authorization with plus.me scope (from NetOpenAuth.Messaging.Channel log):
Incoming HTTP request: GET http://localhost:40004/Me/LoginComplete?from=Google&state=TWXf6Zq3XYSlwyfCDt3GiQ&code=4/qC_KeuiykcVm1sayIyEdnBjiklxz.AoMfk5TqaXQcsNf4jSVKMpY-GxwThAI
After binding element processing, the received EndUserAuthorizationSuccessAuthCodeResponse (2.0) message is:
code: 4/qC_KeuiykcVm1sayIyEdnBjiklxz.AoMfk5TqaXQcsNf4jSVKMpY-GxwThAI
state: TWXf6Zq3XYSlwyfCDt3GiQ
from: Google
And here is (success) authorization response with plus.login scope:
Incoming HTTP request: GET http://localhost:40004/Me/LoginComplete?from=Google&state=26R-O3YN6u3-5EKIlJzFFw&code=4/zOoeVq8vec068x2-CyPq4PjPNtRT.osemzp8Zl7sQsNf4jSVKMpbcmWQThAI&authuser=0&prompt=consent&session_state=27ca4bd2e70d0721bc1fa781b900a558e59fe4c7..d409
After binding element processing, the received EndUserAuthorizationSuccessAuthCodeResponse (2.0) message is:
code: 4/zOoeVq8vec068x2-CyPq4PjPNtRT.osemzp8Zl7sQsNf4jSVKMpbcmWQThAI
state: 26R-O3YN6u3-5EKIlJzFFw
from: Google
authuser: 0
prompt: consent
session_state: 27ca4bd2e70d0721bc1fa781b900a558e59fe4c7..d409
Call for token (for plus.me scope) will be successful:
Prepared outgoing AccessTokenAuthorizationCodeRequestC (2.0) message for https://accounts.google.com/o/oauth2/token:
code: 4/qC_KeuiykcVm1sayIyEdnBjiklxz.AoMfk5TqaXQcsNf4jSVKMpY-GxwThAI
redirect_uri: http://localhost:40004/Me/LoginComplete?from=Google
grant_type: authorization_code
client_id: 175802076419.apps.googleusercontent.com
client_secret: ********
But with plus.login scope 3 new parameters (authuser, prompt, session_state) are transferred to redirect_url param:
Prepared outgoing AccessTokenAuthorizationCodeRequestC (2.0) message for https://accounts.google.com/o/oauth2/token:
code: 4/zOoeVq8vec068x2-CyPq4PjPNtRT.osemzp8Zl7sQsNf4jSVKMpbcmWQThAI
redirect_uri: http://localhost:40004/Me/LoginComplete?from=Google&authuser=0&prompt=consent&session_state=27ca4bd2e70d0721bc1fa781b900a558e59fe4c7..d409
grant_type: authorization_code
client_id: 175802076419.apps.googleusercontent.com
client_secret: ********
And as soon as this redirect_url does not match registered I receive error:
https://accounts.google.com/o/oauth2/token returned 400 BadRequest: Bad Request
OAuth2 spec says that params code and state are required in authorization response and says noting about adding other parameters. But it also says that
The client MUST ignore unrecognized response parameters
Does this mean that this is DNOA issue and not Google one?
May be DNOA must add nullable responseUri parameter to ProcessUserAuthorization and use it instead of guessing from current url...
What's the easiest workaround (except using Google library)?
Update:
Here is original request for /oauth
Prepared outgoing EndUserAuthorizationRequestC (2.0) message for https://accounts.google.com/o/oauth2/auth:
client_id: 175802076419.apps.googleusercontent.com
redirect_uri: http://localhost:40004/Me/LoginComplete?from=Google
state: TWXf6Zq3XYSlwyfCDt3GiQ
scope: https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/plus.me
response_type: code

Reading x-access-Level header for Twitter REST API using omniauth-twitter / twitter Gem

I'm using Omniauth to authenticate users with Twitter through OAuth (using omniauth-twitter gem). I plan to allow normal users to login with just 'read' permissions, and only authorise 'read-write' permissions if/when they decide to create things within the site.
In my Identity model I'm analysing the AuthHash omniauth passes to the create_with_omniauth action, and I'm making separate logic for each provider type, so that I can look deeper into the returned hash schema if necessary.
If I raise auth.to_yaml to output the structure, I see the 'x-access-level' header that I'd like to read, but I don't know how to look into the response: Net::HTTPOK object in order to get to the next level of the structure.
This is the auth structure, cutting out some of the unnecessary details
--- !ruby/hash:OmniAuth::AuthHash
provider: twitter
...
extra: !ruby/hash:Hashie::Mash
...
access_token: !ruby/object:OAuth::AccessToken
...
response: !ruby/object:Net::HTTPOK
http_version: '1.1'
code: '200'
message: OK
header:
x-access-level:
- read-write
x-ratelimit-limit:
- '350'
x-ratelimit-remaining:
- '348'
x-ratelimit-reset:
- '1330798604'
So far I can get to the response with auth["extra"]["access_token"].response but putting .header at the end returns the same response structure, and ["header"] is empty when I raise it.
I'm ok with using the Twitter gem if necessary to do a verify_credentials call inside the Identity model (since Twitter adds the x-access-level header to every response, but even with this approach I wouldn't know how to read the returned headers to read the x-access-level header.
I know this is not the same ruby twitter client but it might help other that arrive here after looking for the same question with the ruby twitter client (gem "twitter").
So going from this call:
twitter_client = Twitter::Client.new(:oauth_token => token, :oauth_token_secret => secret)
twitter_client.verify_credentials
That will give you only the user info json. You can actually get the twitter api response and then check the x-access-level contained in the header
resp = twitter_client.get, "/1.1/account/verify_credentials.json"
resp[:response_headers]["x-access-level"] # "read-write" in my case
Hope this helps others...

Resources