I'm looking to have the client with an access token (reference token) with scope access to call API 1, API 1 will call API 2, API 2 will call Id3 to add the scope (if client is allow) to the access token.
If this possible?
Yes this is possible, all you need is an endpoint on your ID3 project that adds/writes that scope to the same repository/datastore that your IScopeStore uses.
Related
I've been trying to connect Microsoft Power Automate to my API. My API has a OAuth2 Code Flow.
According to Power Automate, the connector can make a connection to my API. and execute a test. But the problem is that Microsoft sends a Bearer token that was generated by them, and not the one that I gave to them via OAuth2, resuting on my API giving a 401 Error (Invalid Token) as expected.
In the Power Automate Custom Connector page, in the security tab I have the following:
Authentication type
OAuth2.0
OAuth2.0 Settings
Identity Provider: Generic OAuth2
Client ID: SomeValue
ClientSecrect: SomeValue
Authorization URL: mydomain.com/auth/authorize
Token URL: mydomain.com/auth/token
Refresh URL mydomain.com/auth/token
Redirect URL: microsoft-flow.com/redirect (Not the real one)
When Microsoft makes a POST request to mydomain.com/auth/token, I return the following body:
{
access_token: "non JWT token", // simillar to a hash
refresh_token: "non JWT token",
expires_in: 3600
}
The request above is final request that microsoft before accepting as a valid connection. The token that microsoft sends me is a JWT one, not the one I provided.
I've seen some guys using Azure AD authentication within the APP, but I was trying to implement something simillar to other platoforms(e.g Github, Spotify, e.t.c)
So my question is it possible to connect Power Automate to a custom API with using OAuth2? If yes, how to do it?
It's possible.
In addition to the OAuth2.0 Settings you listed, there is another important property Scope which you have missed.
Since your API is protected in Azure AD, so I assume that you have created an Azure AD app for your API and exposed scopes.
After that, you can get the application ID URI (api://{clientId}) for your API.
You should put this value into the "Scope" in Power Automate, like this:
Then this access token will be considered valid by your API.
I've done two steps to fix this problem.
Step 1
Previously my API returned the body with access_token, refresh_token and expires_in, but then I added scope and token_type. Example:
{
access_token: "2346ad27d7568ba9896f1b7da6b5991251debdf2",
refresh_token: "4468e5deabf5e6d0740cd1a77df56f67093ec943",
expires_in: 3600,
scope: "none",
token_type: "Bearer"
}
Step 2
Delete the custom connector and create a new one with the same parameters. When I got to the "Test" section, Power automate finally could make the GET request successfully.
In my case, even if the the API was updated, Power automate was still using its faulty token, so I had to delete that custom connector and create new one.
Conclusion
By updating the API and deleting the old custom connector, I was able to get the connector working.
I’m updating a third party app that currently integrates with Twinfield using the session’s method with username and password to use the oAuth method.
In confused by the documentation though... do I still need to use the sessions or when using oAuth do I just call the endpoint(s) by passing the access token in the header as normal?
Also their Soap definition has four properties, the usual ClientID and Secret but also accessSecret? What’s that?
TLDR: you no longer need to use the sessions and SelectCompany; when you have the access token you can use that and the company code directly in the header.
You can obtain the access token as described here.
The documentation is a bit unclear on how to use the access token in your calls.
In the old username/password/session flow, you referred to a SessionID in the SOAP Header, and you would do a SelectCompany call to select the relevant target ("administratie").
In the OAuth flow, the SessionID is no longer relevant. Once you obtained a valid access token, you should set that in the header using the AccessToken field.
Instead of the old SelectCompany call, you can set the CompanyCode directly in the header. So if you have obtained an access token eyWhatANiceToken, and want to retrieve data for company "My Company BV [130001]" you have set AccessToken to eyWhatANiceToken and CompanyCode to 130001 in the header.
You can request the available codes using the list offices call
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.
I have a global account that has several views that I want to use on the server side to embed dashboards for the various views on the client side. From what I understand, I get an access token using a service account on the server side and can then send the access token to the client side whenever needed. I was wondering, is this the correct flow? Should the access token be per session?
The authorization on the client side shown here has a field for a server auth access token, but couldn't find documentation on the exact flow I wanted. Basically I'm unsure what the proper way of generating that server auth access token is. Any help/pointers would be very much appreciated.
[Here][1] is an example of how to set up server side auth. The above code creates a new token when anyone visits the site. You can see the endpoint that gets that access token [here][2].
Below are the general steps to get to a working version:
Step 1: Create a service account and download the JSON key
Step 2: Add the service account as a user in Google Analytics
Step 3: Use the JSON key data to request an access token
# service-account.py
import json
from oauth2client.client import SignedJwtAssertionCredentials
# The scope for the OAuth2 request.
SCOPE = 'https://www.googleapis.com/auth/analytics.readonly'
# The location of the key file with the key data.
KEY_FILEPATH = 'path/to/json-key.json'
# Load the key file's private data.
with open(KEY_FILEPATH) as key_file:
_key_data = json.load(key_file)
# Construct a credentials objects from the key data and OAuth2 scope.
_credentials = SignedJwtAssertionCredentials(
_key_data['client_email'], _key_data['private_key'], SCOPE)
# Defines a method to get an access token from the credentials object.
# The access token is automatically refreshed if it has expired.
def get_access_token():
return _credentials.get_access_token().access_token
Back to the client side:
Step 4: Load the Embed API library.
<script>
(function(w,d,s,g,js,fs){
g=w.gapi||(w.gapi={});g.analytics={q:[],ready:function(f){this.q.push(f);}};
js=d.createElement(s);fs=d.getElementsByTagName(s)[0];
js.src='https://apis.google.com/js/platform.js';
fs.parentNode.insertBefore(js,fs);js.onload=function(){g.load('analytics');};
}(window,document,'script'));
</script>
Step 5: Add HTML containers to host the dashboard components.
<div id="chart-1-container"></div>
<div id="chart-2-container"></div>
Step 6: Write the dashboard code.
Use the access token obtained in step 3 to authorize the Embed API.
gapi.analytics.ready(function() {
/**
* Authorize the user with an access token obtained server side.
*/
gapi.analytics.auth.authorize({
'serverAuth': {
'access_token': '{{ ACCESS_TOKEN_FROM_SERVICE_ACCOUNT }}'
}
});
...
The additional work of creating an endpoint which returns the token depends on your back end implementation but the source code of how the demo does it can be found [here][2].
[1]: https://ga-dev-tools.appspot.com/embed-api/server-side-authorization/
[2]: https://github.com/googleanalytics/ga-dev-tools/blob/abb3c5a18160327a38bf5c7f07437dc402569cac/lib/controllers/server_side_auth.py
I'm not very familiar with Google Analytics, but as far as OAuth goes, the handling of access tokens and refresh tokens should all be on the server-side. The client receives an authorization code and provides that to the server, which then obtains the tokens and uses the tokens to obtain the data necessary. There shouldn't be any need to send an access token to the client.
It might be helpful to read this, which describes the standard OAuth flow:
https://developers.google.com/identity/protocols/OAuth2
I have build a OAuth2.0 Authorization server using dotnetopenauth that will manage authentication, authorization, and assign accessToken to the caller. The caller will use the access token to access the api (webservices) at resource server.
If follow the sample provided by dotnetopenauth in Resource Server, api that builded using WCF can be authenticated by OAuthAuthorizationManager
If using ServiceStack to build my api in Resource Server, how to build the authentication process that verify the incoming api request based on assigned OAuth2.0 access token? The functionality should similar to OAuthAuthorizationManager in the dotnetopenid sample and not based on login session.
Just some update
I didn't use the AuthenticateAttribute or RequiredRoleAttribute from ServiceStack.ServiceInterface.
I create 2 custom RequestFilterAttribute to replace the functions provided by AuthenticateAttribute and RequiredRoleAttribute.
In each custom RequestFilterAttribute's Execute method, I'm using method in dotnetopenauth to verify the access token.
//httpReq==req from Execute(IHttpRequest req, IHttpResponse res, object requestDto)
The code for the access token verification as following, reference the relevant documentation from both servicestack and dotnetopenauth for more info. ResourceServer is class from dotnetopenauth
HttpRequestBase reqBase = new HttpRequestWrapper((System.Web.HttpRequest)httpReq.OriginalRequest);
var resourceServer = new ResourceServer(new StandardAccessTokenAnalyzer(AuthorizationServerPublicKey, ResourceServerPrivateKey));
IPrincipal ip = null;
resourceServer.VerifyAccess(reqBase, out ip);
If the ip is null then not authenticated, if not null, the incoming request is valid and can use the ip to check the role e.g. ip.IsInRole(requiredRole)
I'm not sure this is the correct way to do the checking or not, but it's works for me. Any better solution are welcome.