Announcement Announcement Module
No announcement yet.
Seeking guidance on an OAuth2 use case Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Seeking guidance on an OAuth2 use case

    Thank you for reading this far.

    I am using Spring OAuth2 in the client and on the server.

    I need some moral OAuth2 guidance on how to approach this problem.
    Having considered this problem for several days, it first appeared
    somewhat unique to my particular needs, but in retrospect, it must
    be a common problem many tiered designs face.

    Consider two applications, A and B. A and B can share HttpSession
    state, but they otherwise run in separate JVMs. A is a front-facing
    site application where the user logs in. Depending on how the user
    navigates the site A, B will be called on to present certain web
    views to the user and make calls to backend REST endpoints on the
    user's behalf.

    The sequence of events: The user logs into A. An access token is
    generated and persisted to external store on her behalf. The user
    navigates to a view served by B. B serves the content, but also
    makes REST calls into backend endpoints.

    My design presumes tokens can be and are minted out of band of the
    OAuth2 flow, but are subsequently used by OAuth2 clients. This
    suggests my prototype relies on an implementation of ClientTokenServices,
    which I'm ok with, and I have this much working to a useful extent.

    My questions revolve around what type of OAuth2 flow B should use
    to call the REST endopints. I have three ideas for moving forward:

    1) My original prototype had B using Resource Owner Password
    Credentials flow. While this does work and has a user-ness baked
    into the type of client, it requires in the middle tier B that a
    "new OAuth2RestTemplate(resourceOwnerDetails)" be executed. Because
    the code in B is exactly the same for every user impinging on B,
    creating new templates even in session scope seems very expensive.
    The username/password of the actual user is not required here, as
    the token is already available out of band. It felt odd instantiating
    the detail resource with a dummy username/password as a placating

    2) I am now contemplating using a singleton template based on Client
    Credentials flow in B. All user sessions can use the same instance
    of the template. And by leveraging shared session state between A
    and B, I can essentially retrieve the token at the client call site
    that the client should use.

    3) I had considered using authorization_code flow, but I am bothered
    by the extensive redirect-URI semantics when in fact no redirection
    in that sense ever truly takes place. It feels like an abuse of
    the flow to use it here.

    So, thank you again for reading this far.

    Is (2) the best design moving forward? It assumes that a Client
    Credentials client with a fixed client_id:client_secret (the classic
    issued client id/client secret pattern) can present a token on
    behalf of user Alice, and be granted access to Alice's resources
    --- but to no other user's resources, which is pretty key any
    acceptable design. In other words, I do not want the client to
    have any incidental authority as-that-client that Alice does not
    have a user.

    Thank you very much for your consideration.