Sample code with Servant.

[wpoosanguansit]

I just came across your project and I would like to find out if there is any sample code that shows the framework being used along Servant? I really appreciate your blogs and hope to read more of them. Thanks for your help.

[tekul]

Hi. I haven't actually used servant and I'm afraid I don't have any sample code including it. However, I'm not quite sure what you mean. Although it's intended to be flexible enough to allow different implementations of back-ends, authentication and so on, the project is intended to implement an OpenID Connect server and, as such, it's pretty independent of how a client is implemented. It's not really a framework for building apps (other than customized OAuth2/OpenID Connect servers).

What role do you see servant playing here? Could you elaborate a bit more on what you'd like to achieve?

[wpoosanguansit]

Thank you for your reply. I am looking at a way to use Servant to define the routing/end points with which will have auth endpoints using broth. Is that not what could be achieved?

[tekul]

I'm afraid I'm still not really very clear what you're trying to do. What do you mean by "auth endpoint" ?

An OpenID Connect server is analogous to a "log in with google" link in an application - it provides a trusted third party for a user to authenticate to instead of authenticating directly to the application itself (in fact Google uses OpenID Connect itself these days). So you can think of the Broch server as an alternative to Google. The project is currently only an OpenID Connect Provider - it implements the server (OP). It should be possible create a library which makes the client side of the protocol (the "relying party" RP) easier to handle, but I haven't done anything on that front yet.

[wpoosanguansit]

I think I must have mistaken broch to be something I can use to implement auth endpoints for Servant. Along the line of

-- | a type to wrap our public api type PublicAPI = Get '[JSON] [PublicData]

-- | a type to wrap our private api type PrivateAPI = Get '[JSON] PrivateData

-- | our API type BasicAPI = "public" :> PublicAPI :<|> "private" :> BasicAuth "foo-realm" User :> PrivateAPI

in place of BasicAuth. I have to apologize for the mixed up.

[tekul]

This appears to be saying that PrivateAPI requires Basic authentication to access it. From my understanding, Servant is mostly about implementing APIs which will be called by other applications, so there may not be interaction with a user involved. Basic auth is rather limited in that it requires a username and password to be sent with the request and that may not be appropriate or useful. A typical example is that a client application is accessing a resource on behalf of a user, which is what OAuth2 is intended to handle. In that case, neither the client nor the resource have access to the user's credentials but the client is instead issued a token by the OAuth2 server. From Servant's perspective the behaviour would be very similar to Basic authentication, apart from the validation of the token.

OpenID Connect builds on OAuth2, but the emphasis is on authenticating the user to the client, rather than authorizing the client to access a resource API on the user's behalf.

By the way, I would avoid using the phrase "auth endpoint" as it isn't very clear and doesn't differentiate between authentication and authorization, or between an endpoint which implements or makes use of them (or both).

[wpoosanguansit]

Thanks so much for the info.

On Nov 23, 2016, at 2:24 PM, ___ notifications@github.com wrote:

This appears to be saying that PrivateAPI requires Basic authentication to access it. From my understanding, Servant is mostly about implementing APIs which will be called by other applications, so there may not be interaction with a user involved. Basic auth is rather limited in that it requires a username and password to be sent with the request and that may not be appropriate or useful. A typical example is that a client application is accessing a resource on behalf of a user, which is what OAuth2 is intended to handle. In that case, neither the client nor the resource have access to the user's credentials but the client is instead issued a token by the OAuth2 server. From servant's perspective the behaviour would be very similar to Basic authentication, apart from the validation of the token.

OpenID Connect builds on OAuth2, but the emphasis is on authenticating the user to the client, rather than authorizing the client to access a resource API on the user's behalf.

By the way, I would avoid using the phrase "auth endpoint" as it isn't very clear and doesn't differentiate between authentication and authorization, or between an endpoint which implements or makes use of them (or both).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[tekul]

You're welcome. Hope you find a suitable solution for whatever you're working on.