locked
Tracking WebAPI per session RRS feed

  • Question

  • User1358036820 posted

    I have a webapi and the auth is token based.  The api is using .net core 2.0 and thinking of using idenityserver4 for the token auth.

    What we want to do is for each client that authenticates using their clientid/secret is to create lets say a shopping cart which they can use.  There are a few things to consider here.

    First each time the client calls api token endpoint they get a cart.  This can happen many times per client.  Second they can terminate each cart by calling a singout endpoint.

    My question here is, in a REST service what is the best way to handle this scenario.

    Happy to clear up any questions.  Any advice appreciated.

    Thursday, January 18, 2018 6:43 PM

All replies

  • User475983607 posted

    What  problem you are trying to solve?  User Identity?

    Thursday, January 18, 2018 7:18 PM
  • User1358036820 posted

    The issue of tracking the user in a webapi for the duration of their activity from start to finish for a particular task.  Example, user auths against api gets a session token we track what they did for that particular session until they sign out.

    Details about the app

    The api will be used for a client in their own flow.  Client will make a auth request to our api and pass to us data on each step of their flow until they call out signout endpoint.  At the end we would know what that client sent per session.

    I am looking for some way of not using session state, but the token will be used as a session token will be tracked in database.  The point is simple, follow the user for duration of requests and report back to them what they did on any given participating site.

    Friday, January 19, 2018 10:40 AM
  • User475983607 posted

    Still, the problem you are trying to solve is not clear.  Is the client a server, user-agent, JavaScript?   What kind of token; custom, JWT?  Are you using ASP Session?  My initial reaction is a process has a start and end.  Create a GUID when the process and use the same GUID when the process ends, perhaps store the GUID in a DB.

    Is there any way to post relevant so we can understand what you're doing.

    Friday, January 19, 2018 12:22 PM
  • User1358036820 posted

    This is best explained with an example.

    We use a 3rd party api where we do the following every time a user is on our site.

    Lets say our site has 10 pages.

    When user starts on page1 we call this api and they provide a token

    We use this token on every page the user goes to until they have paid at which point we call an api endpoint that closes/destroys the session (thats what they call it)

    After this process they can tell us what each user did if we provide them with this token or session-token (again what they call it)

    So question:

    What is the best way to implement this.

    Its the same flow used by booking api's which return a token per user and track a booking.

    Should i use something like idenityserver to issue the token and create a session in the backend or should i use some kind of custom token that i can track and destroy when the user calls a particular endpoint.

    Friday, January 19, 2018 7:45 PM
  • User475983607 posted

    I think the problem is persisting a string, session-cookie generated by a 3rd party, per user.  If this is a browser based app then put the session-token a cookie. 

    If you need to report on the session-cookie at a later time then store the cookie in a database table.  

    Friday, January 19, 2018 8:58 PM
  • User1358036820 posted

    Appreciate the response but no its not a cookie as its purely backend communication.  They are able to track activity based on a token string.  I guess i just have to do some custom token store it and track it as that seems to be the logical resolution.  I was just trying to see if there might be an easier way.

    Monday, January 22, 2018 8:34 AM
  • User475983607 posted

    Appreciate the response but no its not a cookie as its purely backend communication.  They are able to track activity based on a token string.  I guess i just have to do some custom token store it and track it as that seems to be the logical resolution.  I was just trying to see if there might be an easier way.

    The problem you are trying to solve is not clear.  Are you trying to persist a token created by a 3rd party or are you trying to design an application that provides the token. Anyway, this is a very basic problem that has been solved.  Keep in mind that IdentityServer uses a cookie to persist the user authentication on the server and it also uses a cookie to persist authentication on the client depending on the flow used.

    Monday, January 22, 2018 11:45 AM
  • User753101303 posted

    Hi,

    It is mixed between auth and carts so I'm not sure what is the exact point.

    From your first post it seems to me your concern is that you may have multiple carts for a single clientid/secret. So my first tought was that you should return a cart id when it is created so that other requests can be done for a particular shopping cart ???

    For now it seems to me there is some confusion about authentication the user and knowing on which entity id he is working ???

    Monday, January 22, 2018 12:23 PM
  • User1358036820 posted

    @PatriceSc Your correct i had some issue i believe making this clear and thats on my part.  The issue is mixed between auth and tracking multiple carts.  The app is an ecommerce with the following:

    Client signs up (simple enough)

    Client can have multiple users per their id (which basically means their one client can have many users)

    Each user can have cart

    Keep in mind the issue is the api design.

    Tuesday, January 23, 2018 8:42 AM
  • User753101303 posted

    Ok so the clientid/secret is just used to have access to your API.

    Then if the API consumer needs to handle multiple entities they need to have an id. When a cart id is created you could return an id that will be sent back in later calls. Or let the user to assign his own id to a newly created cart.

    It doesn't seems to be really different from pretty much any other API call where you usually always work on some particular entity?

    Tuesday, January 23, 2018 9:41 AM
  • User475983607 posted

    You are treating the web server as the client when in fact the user-agent is the client in this scenario.  The problem you are trying to solve is User Identity.

    Keep in mind the issue is the api design.

    This is confusing.  Can you see the token generated from the 3rd party API?  Is the client web application that calls the API under your control?

    Tuesday, January 23, 2018 11:55 AM
  • User1358036820 posted

    What I was expecting to do is have the following setup

    1) IdentitySever (dealing with auth stuff)

    2) API 

    What I was expecting the user to do

    1) Call an api endpoint /token/whatever, that connects to id server with auth details and gets a token and passes it to the client app - can be anything.

    The issue I was trying to solve:

    Pass the token from the API to the user without exposing id server to outside.

    Why?

    Because I wanted to store this token into a db where i can could track it until the user signouts out.

    This was the only way i could think to intercept the token before passing to the user.

    However,

    I wanted the user to signout via the token, example

    Signout/(token)

    Therefore given me the ability to track the tokens on per user bases.

    Because of this i was just thinking of dismissing id server and letting my api create a token and just do what i wanted, but id server implements a number of features which my api would need soon, so i was trying to get it to work with that.

    Again all suggestions appreciated.

    Tuesday, January 23, 2018 12:08 PM
  • User753101303 posted

    Humm still unclear to me. Seems we are switching back and forth between authorization and API usage tracking.

    For now my understanding is that you have your own user that will reach your api using a client id/secret and will get an authorization token.

    Now he will use your API to process request for his own customers A, B and C and you want to provide your own user with a report so that the can track which activity was done on your side for his A, B and C customers. Is this correct ?

    Tuesday, January 23, 2018 12:42 PM
  • User475983607 posted

    I'm familiar with Identity Server and this is how I would solve this problem.  The User is a web browser (user-agent).  The Client is an MVC app secured by Identity Server.  Configure Identity Server to use the Hybrid or HybridAndClientCredentials grant type.  Use the later grant type if you need to secure Web API.

    The user authenticates with the MVC app and Identity Server.  Nothing out of the ordinary here.  Next, the user (not the client) starts the 3rd party token process by clicking a link or a button to makes a request to the MVC app, the client, secured by Identity Server.  Let's call the action GetToken().

    The GetToken() action makes a request to the 3rd party token service and receives the token response.  Next, the token is save in a database table along with the user's identity.  Add the token to a cookie and return the cookie to the User (the browser).  The browser will automatically send the cookie to the MVC app on each and every request from that point on until the cookie expires.  I would create a middleware service so that I can inject the token into the MVC controller and encrypt/decrypt the cookie.

    There are several variations of this technique depending on your design which is unclear at this point. 

    Tuesday, January 23, 2018 2:32 PM
  • User1358036820 posted

    Your understanding is almost correct the user will be any native app.

    Thursday, January 25, 2018 11:52 AM
  • User1358036820 posted

    @mgebhard  Your solution is interesting but not quite there.

    As you are familiar with id server i have the following questions which might help to actually solve this.

    1) Am I correct in thinking that Id server will issue a new reference token every time i request one?

    2) Is there a way that i can intercept this token and store it in the db, the thinking behind this is there is one endpoint that can create a token and do some other tasks, so from the users point of view they just hit token endpoint and everything begins from there.

    Once they have a token and I am tracking it.  I will treat that as a session, and just log everything against it until they sign out.  (Session is used here as just the word, i'm not talking about .net/server sessions, just something that can act as a token until no longer needed)

    Thursday, January 25, 2018 12:06 PM
  • User475983607 posted

    ammd

    1) Am I correct in thinking that Id server will issue a new reference token every time i request one?

    I don't understand the question but I think the answer is no.

    A reference token solves token revocation difficulty that comes with using a JWT.  JWTs are self contained and signed.  The clients validate JWTs sent by the user.  There is no need for the client to communicate with Identity Server to validate the user token.  A reference token is a unique string  that identifies the actual token stored in a table.  The user sends the reference token to the client and the client must send the unique reference to the  Identity Server for verification.  This centralizes the token and makes it easy to revoke a token.

    ammd

    2) Is there a way that i can intercept this token and store it in the db, the thinking behind this is there is one endpoint that can create a token and do some other tasks, so from the users point of view they just hit token endpoint and everything begins from there

    I don't fully understand the first question so part 2 is cloudy as well. 

    What's really confusing with this post and the others is it seems that you don't know where the token is or who the user is.  I get the feeling you might think there is some magical server side solution to identify users.  There's not.  HTTP does not work that way.  Users must provide their identity to the client or service within the request. 

    Are you in control of the UI?  If so, my original design suggest will work.   Otherwise, explain the parts of the systems.  Are you building a pass-through to a 3rd party API?

    Thursday, January 25, 2018 4:23 PM
  • User1358036820 posted

    Appreciate all responses.

    I believe its the writing of the question on my part and keep going round in circles.  Will try and explain the project one more time.

    What I was trying to replicate.

    Imagine a booking API like Sabre.

    1) I connect to sabre and get token

    2) That token is representative of a particular user on my system

    3) That token tracks the booking all the way till i call and endpoint which saves the booking and destroys that token

    I can do this for each user on my app as many times as required.

    I was wondering how given just my client id and secret they produce a unique token each time.

    Just the flow not the technical aspect.  Here is my thinking

    1) Given my clientid/secret they create a unique token store it on their side

    Each time i call the api given this token they look it up save data against it

    When i finish they basically set the booking to complete and that token is no longer in use.

    Technically I can achieve this but having my own code do all this.

    I was wondering if introducing IdSrv into this flow would give me any benefit with the token handling, or stick with a custom solution.

    Hope its a bit more clear now.

    Friday, January 26, 2018 7:39 AM
  • User475983607 posted

    Given your posts, my observation is the the flow is flawed because it ignores the fundamental rule that HTTP is anonymous.  Identity server is a centralized authentication and authorization service and has nothing to do with persisting a string used in the application logic flow.  Identity Server provides Identify services and authorize access to remote services.

    ammd

    1) Given my clientid/secret they create a unique token store it on their side

    Each time i call the api given this token they look it up save data against it

    clientid/secret identifies the client application usually a web server not the user. 

    If the machine with the clientid/secret is under your control then there is no issue.  If the machine with the clientid/secret is NOT under your control then you must establish a data interface that requires the machine to forward the token as it is the client's responsibility to persist the token or the user not Web API.

    Friday, January 26, 2018 12:42 PM
  • User753101303 posted

    ammd

    That token tracks the booking

    You just told it is representative of a particular user (or more precisely you know to who you gave that so he can use this in his application code).

    Plus I doubt Sabre doesn't allow to issue multiple booking transactions before ending the authentication session.

    For now it seems there is really some kind of confusion between an authentication token and generating a unique identifier for the purpose of the API (for example a booking API will likely return an id that the app could keep to later change the booking etc...). It has nothing to do with authentication...

    If you need further help, IMO it should be best to just stop any technical description and describe what you need in plain English.

    For example for now my understanding is that :
    - you want to expose an API to your own customers (perhaps using a clientid/secret)
    - they'll use your API to possibly manage multiple shopping carts for their own customers so the API should likely just generate an id so that you can identify in other calls which shopping cart should be processed in this particular API call but it's entirely unrelated to the authentication (though you should ensure as a safey measure that each shopping cart can be handled only by the api consumer who created it).

    We really have IMO 2 entirely separate subjects.

    Ah or you do call an external API that handles shopping carts for you ?

    Friday, January 26, 2018 1:59 PM