0 Replies Latest reply on Jun 26, 2019 1:50 PM by Timothy Burt

    How to leverage Elytron components for embedded OAuth 2.0 implementation

    Timothy Burt Newbie

      Having been away from WildFly for 5 years, I find myself tasked with creating a minimal OAuth 2.0 IDP implementation, and would like leverage the new Elytron components in an appropriate way.




      • I only need to support the "password" grant type of the token URL
      • I need to leverage existing database tables used by our current (non-WildFly) implementation: one for client credentials (e.g. client_id and client_secret) and one for the generated tokens
      • I need (or, at least, strongly desire) the implementation to be a webapp that is part of our existing enterprise application (ear) so that client applications can remain unchanged (i.e. the current OAuth 2.0 app runs in the same JEE instance as our application, just with a different context root for the token endpoint)


      Logically, at a 1000-foot level, it would seem that I should be able to implement the token endpoint and leverage a custom authentication realm implementation (which, ideally, could leverage a properties-realm for the user/password validation, at least initially) and, when login succeeds, generate the bearer token for the client.  Then, the "main" app would need to validate the bearer token either using the existing database table or an "introspection" URL (which would then also need to be implemented by our new OAuth 2.0 webapp).  If we do provide an introspection URL, would the provided token-realm cache results so that introspection is not required for repeated requests?


      I apologize for the meager information (I am not trying to withhold anything -- I am just not sure how much is relevant, just to get me pointed in the right direction) and would like to say "thanks" in advance for any pointers anyone can provide.  I will try to look through the copious documentation and quickstart links I've found so far...