Brian Demers

I'm guessing you noticed, but it looks like there is a rendering issue on DZone in this section (it's missing the @Mojo annotation), however, you may have already found the code on GitHub or the original post:
https://developer.okta.com/blog/2019/09/23/tutorial-build-a-maven-plugin#write-the-maven-plugin-code

Back to your question! Maven plugins need to be bound to build phases. This happens by default for plugins like the compiler and jar plugin. For other plugins, you would need to add the plugin to a `pom.xml` and add an execution, In this case, using the `version` goal, Take a look at the official Maven docs to learn how to configure plugins: https://maven.apache.org/guides/mini/guide-configuring-plugins.html#configuring-build-plugins

Thanks for following up Rahul! It's been a while since I've been on Windows. Hopefully, you were able to just set the argument `-Dgit.command="cmd /c git rev-parse --short=4 HEAD"`

OAuth 2.0 is actually all about authoriation on this side of the application. And you are trusting thatt whoever issued the token Authenticated the user. For many apps this fine, and is a common "resource server" technique.
OpenID Connect is built on top of OAuth and provides authentication. Take a look at this video for more details: https://www.youtube.com/watch?v=996OiexHze0

If the access token is expired, the Resource Server will return with a 403. At that point, you could make the client retry (with a new access token), or fail. Does that help?

Spring Security _should_ refresh the token for you (assuming you also have a refresh token). In the example above just a single request was made, the access token will only be requested once. Where are you checking the expiration of the access token?

Spring Security 5.x+ uses Nimbus behind the scenes. Is there something specific you are looking for?

I see what you are saying, the session cookie is processed first, and the auth header is not used. To get around this you could disable session handling by doing something like:

chainDefinition.addPathDefinition("/**", "noSessionCreation, authcBasic[permissive]");

What are you using to make the request? Are you using cookies? preemptive auth?

Take a look at one of the project's examples: https://github.com/apache/shiro/tree/master/samples/

Take a look at one of the project's examples: https://github.com/apache/shiro/tree/master/samples/

Sorry for the (very) late reply, but yes, you would just use a different Realm (a custom implementation or one of the existing ones)

That would be the role of the issuing IdP, (the server issuing the token). When the access token is exchanged for user-details/introspection, additional metadata could be returned (or a different set of scopes). Does that help?

The JSR process is and will always be [intentially] slow. Spring (or any other project) doesn't have these same restrictions, those projects will always be able to move faster. That said a lot of shops are not to keep pace with them, but that is a whole different topic ;)

Good question! A couple reasons off hand:

1.) You are supporting mutliple applications, not all of which are using Spring (think Guice, Dropwizard, raw Servlet, etc). Apache Shiro could be used in all of these to keep things consistent between each app.

2.) Migrating an existing web app to Spring Boot