What even is an OIDC CLI?

oidc --issuer=https://issuer.example.com \
--port=5432 \
--client_id=some-client-id \
--client_secret=some-client-secret \
--profile \
--email \
--roles
# Browser launches https://issuer.example.com, using the authorization_endpoint returned by https://issuer.example.com/.well-known/openid-configuration# User logs in, approves scopes `openid`, `profile`, and `email`, and a code is returned to the CLI listening at http://localhost:5432# CLI exchanges code for `id_token` and `access_token`# Information from `id_token`, `access_token` (if a JWT), and `/userinfo` is displayedID Token:
{
"sub": "user",
"aud": "some-client-id",
"azp": "some-client-id",
"roles": [
"user's role"
],
"email": "some@email"
"email_verified": "true|false"
"iss": "https://issuer.example.com",
"jti": "fc7ed671-43e4-4294-aecc-8cf221650135"
}
...etc

It should just be that simple to get an id_token! No…

This is the second article in the series. For the first article, visit here.

Multiple Okta SAML Identity Providers

What’s the best way to register multiple Okta instances in a Spring Boot application as potential sources of identity and authorization?

spring:
security:
saml2:
relyingparty:
registration:
okta1:
identityprovider:
metadata-uri: https://dev-#######.okta.com/app/XXXXXXXXXXXXXXXXXXXX/sso/saml/metadata
okta2:
identityprovider:
metadata-uri: https://dev-#######.okta.com/app/XXXXXXXXXXXXXXXXXXXX/sso/saml/metadata

It’s that simple. The properties are briefly introduced in the Spring Security documentation (5.4.2), and I haven’t been able to find a more detailed description. …

PHAAS? What acronyms you get when everything is as a service

Can’t I hash my own passwords?

Companies have a vested interest in ensuring passwords in their care are handled securely. A centralized PHAAS could help by ensuring that passwords are encoded and verified according to company standards and best practices. Centralizing password hashing also removes security-sensitive code from individual applications and standardizes it in a single location. This also reveals which applications perform password hashing and which algorithms are used.

Why not Hashing-As-A-Service?

I’m not sure that hashing as a generic capability makes a lot of sense as a centralized function. Nearly every modern language has either built-in…

Use Case: I want to prevent creation of a resource that does not meet standard.

Possible Solution: Validating Webhook

How do you make this? Register a validating webhook with a resource definition that looks like the below example (see the K8s 1.19 API reference). In the webhooks: [] section you can specify any number of webhooks.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
name: validating-webhook
webhooks: []

What are those webhooks? In basic terms, they are a combination of one hook and one or more rules. The rules specify which actions and objects will trigger the hook (example: CREATE a pod). The…

If you have a Spring Boot app, chances are you want to allow users to easily login to that app. Here I’ll show you how to use Okta as a SAML Identity Provider to allow your users in Okta to login to your app and preserve their identity.

Create a Dev Account on Okta

To start with, let’s create a dev account on Okta to create the SAML IdP. Start at https://developer.okta.com/signup/. Note that you can use an email that already has an account on Okta, since this email will be a fresh User in the new Okta Dev Account. Once you’re past the confirmation and…

During the past few months I’ve been fortunate to spend a good deal of time with my family. I’ve noticed a few patterns with the kids — patterns I’ve also seen while leading agile software teams and doing technical consulting for seven companies.

Here’s a few scenarios that I found interesting:

Kids: “You only gave me two slices of pizza! I wanted three.”

Parent: “Eat what’s on your plate, and if you’re still hungry, I’ll give you more.”

Developers: “This will take X-big-number weeks to build and deliver.”

Agilist: “Let’s figure out how we can build this to get in…

In part 1 [1] I discussed a strategy that we call “online validation” of tokens, by calling the UAA’s /introspect [2] endpoint and passing in a token for validation. Here I’d like to discuss an alternative strategy known as “offline validation” of tokens. This only works with JWT tokens, since JWT tokens contain the permissions (“scopes”) and are signed by the UAA, so they can be validated and read by any other application.

A JWT token looks like this:

eyJhbGciOiJSUzI1NiIsImprdSI6Imh0dHBzOi8vbG9jYWxob3N0OjgwODAvdWFhL3Rva2VuX2tleXMiLCJraWQiOiJzYW1wbGVfcHJpdmF0ZV9rZXlfRE9fTk9UX1VTRSIsInR5cCI6IkpXVCJ9.eyJqdGkiOiI5ZDM2MmEwMTlhYzA0MzNmYTdiOThjZmIyMjYwZDk5MSIsInN1YiI6ImFkbWluIiwiYXV0aG9yaXRpZXMiOlsiY2xpZW50cy5yZWFkIiwicGFzc3dvcmQud3JpdGUiLCJjbGllbnRzLnNlY3JldCIsImNsaWVudHMud3JpdGUiLCJ1YWEuYWRtaW4iLCJzY2ltLndyaXRlIiwic2NpbS5yZWFkIl0sInNjb3BlIjpbImNsaWVudHMucmVhZCIsInBhc3N3b3JkLndyaXRlIiwiY2xpZW50cy5zZWNyZXQiLCJjbGllbnRzLndyaXRlIiwidWFhLmFkbWluIiwic2NpbS53cml0ZSIsInNjaW0ucmVhZCJdLCJjbGllbnRfaWQiOiJhZG1pbiIsImNpZCI6ImFkbWluIiwiYXpwIjoiYWRtaW4iLCJncmFudF90eXBlIjoiY2xpZW50X2NyZWRlbnRpYWxzIiwicmV2X3NpZyI6IjFlZTRkNGUyIiwiaWF0IjoxNTg3MjIyMTEyLCJleHAiOjE1ODcyNjUzMTIsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC91YWEvb2F1dGgvdG9rZW4iLCJ6aWQiOiJ1YWEiLCJhdWQiOlsic2NpbSIsInBhc3N3b3JkIiwiY2xpZW50cyIsInVhYSIsImFkbWluIl19.I4-C1VY1GmQH4bfAWLXCsxO44C6eUCmBugR30mS6RZmfSazLK5aaZfqVy3B_taOYzf6VcqYGjpRvh7gkQ_gDlbAfRjNizQnP_ZeB3dJwuv_ZGW2bcekcYIyLMp0EFbqExlv6VdCWGes9OmSnmsW0HngXKR_IldJ4rZDu-AyiiNg…

Let’s say you’re an application developer, crafting an application that will be secured by the UAA OAuth 2.0 server. You expose an HTTP endpoint that requires consumers to have an OAuth scope called app-x-read-only.

An HTTP client has called your endpoint, and handed you a token! Now you’re ready to check:

  1. Was this token issued by the UAA instance that I trust?
  2. Does this token authorize contain scope app-x-read-only?

To answer these questions, let’s lay some groundwork for UAA tokens. UAA issues tokens in two formats: jwt and opaque. Your OAuth client chooses which token format to obtain from the…

It’s important that your Cloud Foundry Oauth2 Clients are able to continually interact with the UAA, for example to verify the validity of opaque tokens. But if the client secret needs to be rotated, it’s hard to get the timing just right. After all — there may be some delay until the new secret can be provided to the client application, or require a client application restart.

Fortunately, the UAA allows a client to have multiple client secrets at one time, to facilitate cutting over the client applications from the old secret to the new secret.

To demonstrate, run the…

Joshua Casey

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store