Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You don't really want to login to the API using OpenID. As you said, OpenID is for <em>Authentication</em>, i.e. Who, while OAuth is for <em>Authorization</em>, i.e. am I allowed? But your structure suggest you'll be using an API as a backend and a web app as a front-end.</p> <p>The best way then is to use OpenID on the web-app to authenticate the user, and then the web-app connects to the API and stores the OpenID credentials. The web-app then knows who the user is, and can provide the service. The API has nothing to do with the user, except that it stores its data.</p> <p>The fundamental difference between OpenID and OAuth is its use. In your situation, you could have something like that:</p> <pre><code>-------- --------- ------- | User | &lt;------&gt; | App | &lt;--------&gt; | API | -------- OpenID --------- (OAuth) ------- </code></pre> <p>The User never interacts directly with the API: who would want to manually send HTTP request? (lol) Instead, the service is provided through the app, which can optionally be authorized using OAuth. However, in the case of a single app accessing the API, you can make the app &lt;=> API connection internal and never expose it.</p>
    singulars
    1. This table or related slice is empty.
    1. POhow can I authenticate a user from a web app to an API?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USFélix Saparelli
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI almost agree with your suggestion, but with a restriction: how the webapp can send the openid credentials to the api ? The api must ensure that these credentials are valid for a specific user, it cannot only **trust** the webapp because other application will also be able to connect to the api and could steal the identity of a user. The possible idea would be to send the response of the openid server to the API, including the assoc_handle key and then, the API server would request (again) the openid provider to check the "is_valid:true" and match the user in the db. Am I correct ?
      singulars
      1. PO
      1. USCyril N.
    2. CONo(t entirely). You have to make the distinction between an API which acts as the unified layer between the outside world and your data(base). You could do what you suggested, but that would essentially mean to integrate an app within the API (which could be alright with you, though). As for **trust**, you could easily use public-key encryption and signing to make sure that only your (or approved) app accesses/changes the *sensitive* data. Besides, the OpenID credentials are *just* the URL -- which you assoc with the user. I suppose the user must be logged in to set this assoc, so: no problem.
      singulars
      1. PO
      1. USFélix Saparelli
    3. COWhen you said "signing", you mean between what ? the app and the api ? the user and the api ? the user and the app ? I see how to identify the user for the app (with openid, like you said), but I can't see exactly how the api can trust the app about which user is using the api. You could easily create an app that connect to my api and fake the identity of a specific user in order to get their data. I need to be sure your app is respectful and which user is using it for sure, even in the api. That what I'm missing and can't understand clearly :(
      singulars
      1. PO
      1. USCyril N.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload