Home > Forum > User Voice > Grant permission for users to access the rest api

Grant permission for users to access the rest api
0

MVP

We created a set of powershell cmdlets to connect to a portal, start/update/delete workflows and adding attachments.

Inspired by the -UseWebLogin parameter off the Connect-PnPOnline cmdlet i extended our powershell cmdlets with a use weblogin feature. Fiddler and a bit of research in the web provided the right approach quite fast.

Authentication works fine, but when using the rest api i receive an "invalid scope" exception.

Seems that the rest api is only working with registered apps.

Would be super cool having the possibility to grant permissions for using the rest api also for users and not only applications.

Btw:
I reused the code for the weblogin from my powershell and extendend https://github.com/WEBCON-BPS/RestApi-DataImporter, but....

Hi Markus, could you go a little further on the scenario you want to achieve?
From what I understand, at the moment you have successfully get the token from the studio endpoint and want to use it for public api endpoints and hence the scope error.

Regarding api support without dedicated accounts, I'm pretty sure we'll always need registered apps, but that doesn't prevent you from using the api as a user.
Before version 2022 and in lagacy apps, you could use impersonation for this, endpoint api/login should return all needed scopes. In the latest version, you can use UserContext and either the authorization code or implicit grant flow. However, both of these flows require user interaction.

The only missing piece that might come in handy is some kind of delayed authentication flow where the user could accept all app consents, for example via a link from an email. Did you mean something like this?

MVP

Hi Kamil

We are having some administrative tools where we don't want to use app registration. Browser based authentication would make the usage easier.
Like PnP powershell has this option for authentication.

In the link below you will find an extended version of the rest-api dataimporter, where i tried to implement a Use-Web-Login option. It works well so far, but as i wrote before, i receive a "invalid scope" exception when i use the extracted token.
Could be that i missed some point.

https://nexplore-my.sharepoint.com/:u:/g/personal/mj_nexplore_ch/EWnOFXi9WWRAgLeYiKomf1cBrkpyiUINJVRRa5jMP38Sbg?e=HcUPAI

You mentioned the UserContext and the authorization code and implicit grant flow. Where can i find documention about this options? Could they help to achieve what i want.

In reply to: Markus Jenni

Hi Kamil

We are having some administrative tools where we don't want to use app registration. Browser based authentication would make the usage easier.
Like PnP powershell has this option for authentication.

In the link below you will find an extended version of the rest-api dataimporter, where i tried to implement a Use-Web-Login option. It works well so far, but as i wrote before, i receive a "invalid scope" exception when i use the extracted token.
Could be that i missed some point.

https://nexplore-my.sharepoint.com/:u:/g/personal/mj_nexplore_ch/EWnOFXi9WWRAgLeYiKomf1cBrkpyiUINJVRRa5jMP38Sbg?e=HcUPAI

You mentioned the UserContext and the authorization code and implicit grant flow. Where can i find documention about this options? Could they help to achieve what i want.

We recently updated the article on authentication and added one about scopes, take a look at them:
https://developer.webcon.com/docs/registration-and-authentiaction/#oauth-20-authorization-code
https://developer.webcon.com/docs/scopes-and-permissions/

In short, we've added support for two additional authentication flows in the oauth 2.0 standard. I think authorization code (maybe with a refresh token) should be enough for your scenario.

I also looked at the code you included, the "invalid scope" error is due to what I mentioned earlier. In version 2022, the security of the public api is based on scops, each endpoint has a certain set of required scopes (described in swagger), while the login account/tokenLogin endpoint you used returns token with scopes used only by studio.