I am developing an app in .NET. I'd like to know if it's possible to OAUTH a .NET SDK backend app using a token. I have a front end app that will be having the token, is it possible to pass it on to my backend app and use it to give OAUTH authentication to my app with the SDK? or will this method only be useful with regular REST calls to the API? Just wondering if I can use some function in the SDK to bypass the login and just provide the token for authentication.
A second question, is there a code example for OAUTH authentication with .NET SDK? I have it for javascript but couldn't find an example for .NET in Genesys websites.
Really not clear what you're trying to do here. a token is a token is a token. Anything can use a token to authenticate. You can pass it, store it , whatever, but generally your back end and front end have entirely different roles and objectives and data needs and you would want separate OAUTHs for each to both segregate those concerns and to provide them each their own rate limiting rather than two systems that aren't necessarily synchronized both trying to do simultaneous actions against the same resource pool with a way to coordinate whose turn it is.
I have an APP in the APPS TAB in genesys CTI that calls this example url: localhost/MYAPP. This url shows a frontend, VUE.JS app that is authenticated with token implicit grant. This frontend shows a button, a "make call" button. Now, the logic to make the call is going to be in the backend, so my question is can I use the token generated in the VUE.JS frontend app and pass it to the backend so the backend can make the API call using that token? and can I do this using the SDK? My frontend is separated from the backend, different projects. That is, the frontend will be calling my backend with an API call. This means the backend will also be need to be authenticated, but I need to authenticate as a user, (i.e. because I'm making calls). So what is the best option? pass the token from the front to the backend? The idea is that the Agent shouldnt have to be shown the login page multiple times.
In the SDK I could only find the following code:
var accessTokenInfo = Configuration.Default.ApiClient.PostToken("CLIENT ID",
"HANDLE CLIENT SECRETS AS PASSWORDS",
"http://redirecturi.com/",
"xxxx ");
But this requires an authorization token. This means the agent needs to login to obtain that. That is the problem, I get the feeling evrytime the backend is called the agent will need to login and we do not want that. So is there a method like the one above that only requires a token to be able to subsequently call a method like this one:
var apiInstance = new ArchitectApi();
DataTableRowEntityListing result = apiInstance.GetFlowsDatatableRows(datatableId, pageNumber, pageSize, showbrief);
If your front end is authenticating as a user it can pass the token created from that to the back end to use as if the back end were the user without doing a subsequent authentication process. Once created a token can be used by anything until it expires. It's just text and can be passed as part of an API payload as long as you're comfortable your connection is secure.
You would just initialize your back end with;
Configuration.Default.AccessToken = token;
Rather than acquiring a new token of it's own through
This is the same concept a back end service uses when they serialize a token to a repository to continue using it throughout the day instead of asking for a new one every time they need to do something.
But there is no way for the back end to authenticate as a user on it's own independently.
The only non-interactive are with their own OAUTH tokens, but a sufficiently scoped OAuth can interact with most user resources.
Configuration.Default.AccessToken = token;
var apiInstance = new ArchitectApi();
DataTableRowEntityListing result = apiInstance.GetFlowsDatatableRows(datatableId, pageNumber, pageSize, showbrief);
but it returns:
Exception when calling ArchitectApi.GetFlowsDatatableRows: Error calling GetFlowsDatatableRows: {"message":"Invalid login credentials.","code":"bad.credentials","status":401,"contextId":"06f9e0c0-4f6e-4161-ba3a-584e7c9855fb","details":[],"errors":[]}
Am i missing something? The token is correct cause I use it on postman and works.
Just keep in mind with this approach if you have multiple users you may need to create an internal dictionary of user/token to ensure the right user/token get used for the right back-end action. Without that sort of mapping you can run into differences in who can access or perform what and loss of traceability / accountability if the all actions are pegging under whoever authenticated most recently not who is actually responsible for initiating them.
ok, another thing that just came up, when I made the API call, it seems that the result is 200 OK but the Entities field is returned empty:
as you can see, some of the other fields are not empty and it does show that there is 7 items (rows) in the datatable, but why do the Entities return null? This doesn't happen when calling the same endpoint from postman:
That one I don't know, you have a Total and page count and page number and page size so it's obviously sort of succeeding, it looks like a deserialization error making the entities unparse-able. You may need to muck with your serializer settings to get it to properly map. First check your sdk is up to date though. If it still does that I know I had to add;
in my setup routine at one point to fix an issue, but yours could be nearly anything.
May want to run the results you're getting back in postman through a JSON parser to see if there's something specific throwing it off you can tweak settings for.
@marisa.grasso From your screenshot, I'm seeing PageCount: 1, PageSize: 56, and Total: 7. But then PageNumber: 56. This means that there exists 1 page of results with a total of 7 results on it, but you've requested the 56th page. I would expect the entities to be null in this situation. If you request the first page, do you get values for Entities?
Please reset your oauth client's secret immediately; your secret was posted publicly on the internet. Client secrets must be handled with the same sensitivity as a password.
