Using OSMT APIs from an external application written in NodeJS/Python/ect...

[ionataniq4]

Hi,

We are currently looking into how we would go about using OSMT APIs from an external application written in NodeJS/Python/ect.

We would like to perform the following in our external application written in NodeJS/React through the use of the OSMT APIs:

• Read RSDs from our OSMT instance
• Search for RSDs from our OSMT instance
• Create/Update RSDs/Collections in our OSMT instance

I assume the above APIs are behind authentication, so we would have to pass an Authorization token with every request we make from our external application to the OSMT instance? What would be the best way to go about integrating something like this?

Thank you for taking the time to look into this.

[JohnKallies]

Hello Ionatan,

Thanks for sharing your question here. From our email thread, I was headed one way with some suggestions. I think I assumed your use case was more curl for batch importing. The Authorization header and Bearer token from OSMT will work when added to curl commands, and you could lift that from a browser request. But I see from your question here that you have a separate application you want to integrate. I'm reading your question as "how to I authenticate to OSMT's API from a different client?" Please confirm that I'm pointed to what you are asking?

I need one additional clarification before I can respond... Is your alternate client browser-based, or hitting OSMT's API from a server?

Thank you...
John

[ionataniq4]

Hi John,

You're spot on, we want to authenticate to OSMT's API from a different client. We would like to hit OSMT's API from a server.

Thank you,
Ionatan.

[JohnKallies]

The more I look at this, the more I realize I don't understand your environment and requirements.

I'm 95% sure that OSMT uses an OAuth 2.0 "Authorization Code" flow. This flow is probably not optimal for your NodeJS app using OSMT's API. For that, you probably want more of a OAuth 2.0 "Client Credentials Flow". That said, OSMT wants a user, (1) to know who updated what changes and (2) to distinguish between public anonymous API searching and authenticated access (anyone authenticated is authorized to update data). Long ago, I worked on a Java Spring app where we passed the Bearer token from the client request through to the external API. The requirement was that the web user was attached to the API usage (not unlike it would be for OSMT), so it's not impossible. In all cases, you'd probably want to build some kind of "OSMT service" in your application that wraps OSMT API interactions. This isn't stuff you want leaking out into other implementations.

Some ideas, completely untested and open to criticism / correction...

• You could have your NodeJS and OSMT applications use the same Okta application / secrets. My guess is that logging in with your NodeJS app and passing that JWT through to OSMT's API might do the trick (similar to what I described above). Thus your NodeJS user is also your OSMT user. Without reimplementing OSMT to use a client credential flow, this might be the strongest option.

• You could implement your NodeJS app so it authenticates to OSMT via Okta, and manages its own auth token, re-authenticating on demand. Kind of an "OSMT wrapper". In this approach, your OSMT would more-or-less use an application service account. This isn't ideal in OSMT, as there is meaning in knowing who did what in the data. I don't feel great about this... :-/

• For your local OSMT, you could monkey with the changes in this commit (Revert "Revert "Allow anonymous API acess to search and list endpoints for published skills and collections"" #64). Prior to this, the API was only secured by an implementation of WebSecurityConfigurerAdapter. If "all" was permitted (see a local development Spring profile called "noauth"), then the API access was open/anonymous. This change in question added a business rule that requires an @AuthenticationPrinicpal (a JWT) to interact with some aspects of OSMT's API. To me, this is the worst of both worlds for your case... no auth in your API and no record of who made what changes. This approach is a little dangerous for anything beyond local development.

I hope that helps. If you want to architect this well, you might be headed towards a client credentials flow. Regardless of how you approach it, would you please share your insights back with the OSMT community?

Thank you

[drey-bigney]

Hi Ionatan,

To build on the information that John's provided, in the past I've leveraged a client credentials flow for these types of service-to-service integrations. Okta has some fairly detailed instructions here and I suspect most IdPs will provide have similar functionality.

Regards,

Drey