Does changing the "Scheme" or the "Authentication" warrant a version increment of an API?

Not applicable

Hi,

Does changing the scheme from say http to https (ignoring you should use https everywhere), and changing the authentication from say basic auth to Oauth2 or OIDC warrant a version increment?

Say we change the auth in a production API from OAuth2 to OpenID Connect?

Then how does one handle this across environments? For example:

Dev we use http and basic auth (quick and dirty)

SIT we use http and OAuth2

Prod we use https and OAuth2

0 3 275
3 REPLIES 3

  1. Changing from http to https -> irrelevant. This should never happen because you always used https in the first place. If you had actually exposed http endpoints, shame on you. Changing doesn't require a version upgrade. Just a 301 status code.
  2. Changing from OAuth v2 to OpenID Connect. This is sort of a moot question, because OpenID Connect is just an authentication layer on top of OAuth v2. The outcome of either one of them is a token, which you presumably use for authorization. So I'd say the OpenID Connect is fully backward compatible with OAuth and there should be no impact on the design of the API, if you add OpenID Connect as an option. Keep in mind the JWT that gets issued as part of OpenID Connect is the "new thing" - the thing that distinguishes it from bare OAuth v2 . And that token is an ID Token , a token that identifies the subject, presumably a person. That JWT is not a replacement for the opaque oauth token. It's a complement to it; it's an entirely different thing. The idea is to assert some information in a signed payload for the APP to use. Eg, the app on the mobile phone now knows who is clicking the buttons. That's not useful for authorizing API endpoints.

As for using different security in dev, sit, and prod - I am firmly against such a practice. You may wish to use an API Gateway like Apigee Edge only in some environments, so you could do system tests in dev with no gateway, no security whatsoever. That seems fine, and is probably better than using "Basic Auth" or API Keys. Those things feel more dirty than quick to me, if you get what I mean.

But in integration environments, you need the actual gateway doing the actual things it will do in prod. Therefore , you need full OAuth2 or openid connect or whatever you decide.

As for http vs https - always always always https. Good hygiene.

This is just, like, my opinion man.

Thanks @Dino

I completely acknowledge https should be used everywhere, but the reality is just because people should use https everywhere, doesn't mean people will.

I understand Google didn't use HTTPs everywhere internally until a couple of years ago.

I guess the question is more around the SDLC, from working locally, to progression through whatever environments a company may have.

As for the OAuth2 to OIDC, that was a bad example (I'm not a developer), but I think you got what I was trying to express.

What about moving from a crappy authentication method to a better one (without being specific)?

What separates developers like you who work at companies like Google vs the rest of the world is you have the knowledge, discipline and resources to consistently work at this level. You opinion as valid as it is might not be practical in some organisations.

If you don't have some form of Auth on your APIs, do you just not run your authentication tests in environments like SIT?

The thing is I still don't know if it is a "no"? I thought it was a "no", but now I'm not so sure...

I get what you're saying about Google and non-Google places. Every organization is different.

It feels like this would be better discussed with a live, whiteboard conversation.

But differences from one shop to another aside, Integration test for sure should use the authentication that you expect to use in production, no?

I would want to use https and oauthv2 in SIT, if I am expecting to use. oauthv2 in production.

(Actually I would never want to use OAuthV2 without https; the spec for OAuthV2 requires https)