We registered the OAuth service and even built the authorization server separately, but that doesn't mean it's immediately usable.

In this chapter, we apply for OAuth service review so the OAuth service can be used fully.

Applying for an OAuth service doesn't mean you can immediately use OAuth fully. Most Service Providers offer their service split into stages.

The reason is security. Using an OAuth service means being able to receive the user's authentication info and call the user's information.

If a malicious site abused this, personal information security problems could occur very easily.

Because of this, most service providers split their service into a test stage and a production stage.

This is the stage where you can use the OAuth service in a limited way.

There's no problem building the authorization server with the provided API info and running it, but you can only use the OAuth service with designated accounts.

Because of this characteristic, it's not suited for a service that targets an unspecified general audience.

When you apply for OAuth, it's automatically set up in the test stage, and only after going through review can it be used in the production stage.

Depending on the service provider, the test stage may be broken down further, or in some cases the test stage may not be offered at all.

This is the stage where you can use the OAuth service without restrictions.

Unlike the test stage, which could only be used with designated accounts, it can be used with any account.

To use the production stage, you must meet the review or policy requirements set by the service provider.

Service providers review the services applying OAuth to check whether the service is trustworthy enough to be granted use of OAuth.

The platforms currently applying the OAuth service are as follows.

• NAVER
• Google
• KAKAO
• GitHub

Let's apply for OAuth service review for each platform so that any account can access the OAuth service.

When you register an OAuth service with Naver, it's registered as being in the development stage.

At this stage, only registered accounts can log in.

Let's go through review to switch it to deployed mode. The review tends to be fairly strict.

Among the 4 platforms above, it also requires the most materials.

After logging in, go to the Naver Developer Center.

Go to the [Application - My Applications] menu in the top header.

Click on the application you want reviewed.

If a logo hasn't been registered yet, register one first. You need a logo in order to apply for review.

That logo image will be shown on the Naver login window.

Since it's required, if you don't have a suitable logo, just make one and use it.

You can specify the logo image in [API Settings]. The supported extensions are jpg, png, and gif.

Then click the edit button to finish.

You need to verify and submit supporting materials for the two items below.

• Whether the information designated as required/optional is actually being properly utilized
• Whether the service is properly applied
• Whether the type of service applying for OAuth is appropriate

You need to provide evidence that the information designated as required/optional is actually being used meaningfully in the service. It seems intended to prevent requesting information that isn't really needed. It's a policy that forces you to use only the information that's truly necessary, and only where it's necessary.

For this project, since the related information is displayed at login, I attached a screenshot of that page.

You select one of the items below.

• Applied to new member sign-up via Naver ID login
• Applied to simple login authentication without sign-up
• Applied to some features, such as writing board posts or comments
• Other

Since this project only performs login, I selected option 2.

You need to provide evidence that Naver ID Login is properly applied and usable. It seems intended to verify there's no issue with the login process.

You can provide screenshots following the login process, and for this project, I recorded the whole sequence and provided it as a gif.

For sites offering certain sensitive services, additional supporting materials are required.

• Services offering sports betting, or activities similar to issuing lottery tickets
• Services selling alcohol online
• P2P web-hard (file sharing) services
• Tattoo services
• None

Since this doesn't apply to any of the services above, I selected option 5.

Once the material upload is complete, apply for review.

Review typically takes about 1 to 3 days.

There were a bit of ups and downs getting through Naver's review.

At first, since this was simply a project that only performed OAuth login, there wasn't much to write, so I just carefully took screenshots of the page showing the email and name, and the login process, and sent those in — but I got rejected.

???: Write the reasons clearly.

The review was rejected.

They asked me to include the reasons for the review as well, so I carefully filled in what seemed like the necessary reasons and requested a re-review.

???: Ah, just mark something that simple as "in development" ^^

Hmm... I guess the project is just too simple, so Naver doesn't really have a particular reason to approve the review.

Still, since every other platform was in production mode and having only Naver stuck in test mode looked odd, I decided to apply for review one more time.

I judged that the current approach had no chance of winning, so I decided to show Naver my own version of "sincerity," done the way they seemed to want.

My approach was the classic proposal-style PowerPoint. Even I couldn't think of a solid reason why the OAuth review absolutely had to be approved, so I submitted it as a PPT, half-jokingly loaded with a nuance along the lines of "everyone else has this activated — are you really going to leave just yours off...?"

I figured if even this attempt failed, I'd just cleanly give up on Naver, and I even mentioned in the PPT that if even this didn't work, I wouldn't bother them any further. Now there was nothing to do but wait.

Wait, seriously?

It worked.

I'm not really sure why it got approved. Maybe it's because I wrote the reasons well after all, or maybe it was originally not supposed to be approved but they just went "sure, fine, whatever, lol."

Anyway, the Naver application is done, and I think it was a pretty fun experience overall. When you apply for review, don't get intimidated just because your project is simple — try putting as much sincerity into it as you can.

• Naver ID Login Application.pptx

This is the PPT I attached. If you're curious, feel free to check it out for reference.

When you apply for the OAuth service with Google, it's registered in test mode.

To switch to production mode, follow the steps below.

Go to Google Cloud Platform, where you registered the OAuth service.

If you haven't registered a logo image yet, register one.

Click [OAuth Consent Screen], and on the screen that appears, click [Edit App] to add a logo.

On that page, click [Publish] to switch to production mode.

It changes to look like this. Selecting [Back to Testing] lets you revert to test mode as before.

Click [Prepare for Verification] to verify the application.

Fill in the required content and submit it to start the review.

Google says it takes about 4 to 6 weeks, so wait patiently.

When you apply for the OAuth service with Kakao, it's registered in a limited production mode.

Kakao's review approach is a bit unusual. Even without going through a separate review, every Kakao account can use the OAuth service without restriction.

This is the opposite approach from Naver or Google, which have a separate test mode, require a separate review, and only then open up access.

Kakao's difference shows up in the consent-item selection.

When selecting information to provide, some information can't be set as required because it's flagged as needing inspection.

For this kind of information, you can only set it as required after separately applying for a business app and passing review.

But here's the problem — true to its "business" name, it requires a business registration number for review...

So does that mean individuals can't apply at all? Not quite. You can check a Kakao developer's response about this at this link.

• App name
• Application ID
• Application owner's email
• Whether identity verification is complete
• Purpose of the application

It seems you can post to the dev talk board with all of the above items filled in without missing any.

They recommend registering an app name that fits the application's character.

• test
• 테스트 (test, in Korean)
• oauth2
• 로그인 (login, in Korean)

Generic names like these seem to be discouraged, so pick a name that reflects the application's identity.

With Kakao, anyone can log in even without applying for review, so whether to apply is entirely optional.

• Application example

I applied as shown above.

I wrote it up at night, and it was approved the very next morning. The Login API doesn't seem to require any particular documents or supporting materials, so feel free to apply without much worry if you'd like to.

Now I can receive email as a required item!

Since GitHub operates in production mode immediately upon service registration, there's no review process.

The moment you create an OAuth App, it can be used by any GitHub account.

We went through OAuth service review for the platforms applied in this project.

Once all reviews are complete, anyone will be able to use OAuth login without restriction.

With this chapter, the technical portion of the OAuth authorization server development journal is wrapped up.