Greetings:
Here’s a newbie question for you all:
I’ve just built and tested my first REST API using the djangorestframework libraries. The purpose of the API is allow access to content (XML) created at the Django site with a SharePoint workflow as the client. The API works fine on localhost:8000 and now I’m setting up a web server so it can be accessed by SHarePoint and other systems on my company’s LAN.
At the present time there is no authentication required to access the API but since the Django server and all API clients are behind a firewall this shouldn’t be an issue. However, thinking ahead to a day when the API may be available over the Internet, I am investigating ways to control access. What is the simplest way to do this? I am looking at using Oauth2 for this but it’s possible that this is overkill (there are only a few clients that may ever call the API and all of these will be known in advance and under my control). SharePoint will be able to pass simple credentials such as username and password, so is that sufficient? If Oauth is the right answer, which grant type is appropriate, Authorization Code or Client Credentials?
Thanks in advance.
@CodenameTim - This one seems more in your wheelhouse than me, care to pitch in here?
Thanks @KenWhitesell. @baltner I’d agree OAuth2 might be over doing if there are only a few clients using it and if the data it protects isn’t going to ruin someone’s life if it leaks. If that’s the case using username and password is fine, assuming SharePoint stores that information securely and the requests are issued over HTTPS properly.
However, if those assumptions aren’t true or start trending towards not being true in the future, there is a library that should help you implement OAuth2 (Getting started — Django OAuth Toolkit 2.2.0 documentation). A cursory look at sharepoint workflows made it seem like they support OAuth2 integrations out of the box. So that may not be a ton of work to setup.
I’d be curious if you could use Tailscale to prevent people not in your network from accessing it as an additional security measure.
Other aside, SharePoint workflows apparently were deprecated in favor of Power Automate.
Thanks for the reply, Tim. I did read most of the OAuth Toolkit documentation and worked through the tutorials but can’t get it to work. That’s why I asked about which grant type would be most appropriate for this use case. It seemed to me that the Client credentials type was most likely the one since I’m both the resource owner and the client but I read in a book that this is rarely used and I should stick with Authorization Code grants.
As for MS deprecating SharePoint workflows, that’s still a few years off (2026 for on-prem servers). We have a plan to deal with that but in the meantime I’d like to get this working with access controls for use on my network. I’ll take a look at Tailscale.
Ah, sorry about that. I think the grant type would be dictated by what SharePoint workflows support. My guess is that it’d be Authorization Code.
I’ve gotten it to work, finally, using the “custom user” approach described in William Vincent’s drfX example app (GitHub - wsvincent/drfx: A framework for launching new Django Rest Framework projects quickly.). It’s not OAuth but it is token based and a good fit for my use case. Adding the token generated for a test user in the request header allows me to do just what I was looking for. Thanks!