I'm fiddling around with the component and I noticed that every oAuth client that I can create is usable for authentication on every configured API. Is there a method to prevent this? How can I fix a Client to one (or a set in the same component) exposed API?
Greetings,
Vincent Koning
The version 4.0.0 fixes the demo modules that were broken by the error above.
That's a matter of authorization, not authentication, is it not?
Yes but also not really. It is common in oAuth2 authentication to have multiple applications/clients configured. For my API I have one (App A) and for my client I also have one (App B). App B will request an authorization token for App A via the iDP. You can then create a restriction in App A so that only App B can get a authorization token but not App C. So a part of the authorization can happen at the iDP and is recommended to do in case of machine-to-machine authentication. The whole App A and App B relationship feature is not available in this app but is not that big of an issue as long as I can analyse the token before the authentication happens.
Currently I don't see any methods before authentication that could help me analyse the token to check for the application/client that provided the token so I can determine if the origin is at least valid.
Note that I don't login a normal user that will then get an OutSystems role. It is about machine-to-machine authentication with no real user involved.
Ah, got it! Thanks for the explenation.
Hi Vincent.
You could probably use two scopes for the two APIs, and require the correct scope in the OnAuthentication callback using CheckScope() function. You can check an example of how to use scopes in the demo of this component.
Alternatively, if you're using an authenticated user (either by configuring the machine-to-machine authentication in the backoffice, or by using authorization code flow), you could use roles and allow access to each API based on the roles a user has.
Unfortunately, an OutSystems change made in 11.13 has broken this component (at least if you want to use scopes as you can see in the demo). I can no longer work on this component until they fix said issue. There is a problem created for it (RPM-1480) which was created a year ago, but no timeline for a fix has been given to me. If you need more features on this component, I suggest you contact OutSystems support asking for an ETA on a fix for RPM-1480, and explain that this problem is preventing the evolution of this forge component.
Thank you.
Hi Leonardo,
Thank you for the update. I will create a ticket for the status of RPM-1480 and also discuss this with our CSM.
Vincent
Just to make sure. In any version after 11.13 it is not possible to use scopes as authorization feature. Or is this just about the demo?
And what is happening that is causing this issue? I don't want to get into a big discussion with support about something that I don't know the context of.
You can still use scopes but you would need to change the architecture of the Scope static entity a little bit and use hardcoded strings.
You can see in the demo that the ProfileScopes static entity aggregates all scopes of the demo application, and it's being used to call DefineOAuthScope so the backoffice knows that these scopes exist and can be assigned to clients.
This static entity can also be used when calling CheckScope to avoid having hardcoded strings (note, for some reason I forgot to make this change in the demo application, so if you download the demo application you'll see it still uses hardcoded strings in CheckScope):
Because of RPM-1480 you can't publish the demo application, and the error you get is the following:
You can still use scopes if you don't use the static entity and use strings instead, but IMO that's a worse architecture, and that's why I am waiting for the fix before I resume working on this component.